NAVAL  POSTGRADUATE  SCHOOL 
Monterey,  California 


19980102  156 

THESIS 


VIDEO  CONFERENCING 

USING 

PACKET  RADIO  TECHNOLOGY 

by 

Narongchai  Nimitbunanan 

June  1997 

Thesis  Advisor: 
Second  Reader: 

Chin-Hwa  Lee 
Supachai  Sirayanone 

IMQ  INSPECTED 


Approved  for  public  release;  distribution  is  unlimited. 


REPORT  DOCUMENTATION  PAGE 

Form  Approved 

0MB  No.  0704-0188 

Public  reporting  burden  for  this  collection  of  information  is  estimated  to  average  1  hour  per  response,  including  the  time  for  reviewing  instruction, 
searching  existing  data  sources,  gathering  and  maintaining  the  data  needed,  and  completing  and  reviewing  the  collection  of  information.  Send 
comments  regarding  this  burden  estimate  or  any  other  aspect  of  this  collection  of  information,  including  suggestions  for  reducing  this  burden,  to 
Washington  headquarters  Services,  Directorate  for  Information  Operations  and  Reports,  1215  Jefferson  Davis  Highway,  Suite  1204,  Arlington,  VA 
22202-4302,  and  to  the  Office  of  Management  and  Budget,  Paperwork  Reduction  Project  (0704-01 88)  Washington  DC  20503. 

1.  AGENCY  USE  ONLY  ^Leave  d/a/7^; 

2.  REPORT  DATE  3.  REPORT  TYPE  AND  DATES  COVERED 

June  1997  Master’s  Thesis 

4.  TITLE  AND  SUBTITLE 

VIDEO  CONFERENCING  USING  PACKET  RADIO  TECHNOLOGY 

5.  FUNDING  NUMBERS 

6.  AUTHOR(S) 

Nimitbunanan,  Narongchai 

7.  PERFORMING  ORGANIZATION  NAME(S)  AND  ADDRESS(ES) 

Naval  Postgraduate  School 

Monterey,  CA  93943-5000 

8.  PERFORMING  ORGANIZATION 

REPORT  NUMBER 

9.  SPONSORING  /  MONITORING  AGENCY  NAME(S)  AND  ADDRESS(ES) 

10.  SPONSORING  /  MONITORING 

AGENCY  REPORT  NUMBER 

11.  SUPPLEMENTARY  NOTES 

The  views  expressed  in  this  thesis  are  those  of  the  author  and  do  not  reflect  the  official  policy  or  position  of  the 
Department  of  Defense  or  the  U.S.  Government. 

12a.  DISTRIBUTION  /  AVAILABILITY  STATEMENT 

Approved  for  public  release;  distribution  unlimited. 

12b.  DISTRIBUTION  CODE 

13.  ABSTRACT  (maximum  200  words) 

Information  and  its  effective  delivering  means  are  becoming  more  and  more  important  in  today’s 
world.  Video-conferencing  is  a  highly  effective  means  to  deliver  information  since  it  is  interactive.  This 
thesis  studies  the  packet-radio-networking  technology  that  can  be  used  to  support  video-conferencing 
applications.  The  popular  networking  protocols,  i.e.  the  Amateur  X.25  (AX.25),  the  Transport  Control 
Protocol/  Internet  Protocol  (TCP/IP),  and  other  protocols,  widely  used  in  packet  radio  technology  are 
described.  By  using  the  File  Transfer  Protocol  (FTP)  of  the  TCP/IP  standard,  the  average  speed  and  time  of 
various  file  sizes  across  a  half-duplex  radio  channel,  a  full-duplex  emulated-radio  channel,  and  a  RS-232  link 
were  collected  and  analyzed.  Finally,  comparisons  were  made  among  channels,  including  the  effects  of  an 
additional  routing  node. 

SUBJECT  TERMS 

Video  Conferencing,  Packet  Radio,  Amateur  Packet  Radio,  AX.25,  TCP/IP,  TNC,  Routing 

15.  NUMBER 

OF  PAGES 

102 

16.  PRICE 

CODE 

17.  SECURITY  CLASSIFICATION  OF 
REPORT 

Unclassified 

18.  SECURITY  CLASSIFICATION  OF  THIS 

PAGE 

Unclassified 

19.  SECURITY  CLASSIFI¬ 
CATION  OF  ABSTRACT 

Unclassified 

20. 

LIMITATION 

OF  ABSTRACT 

UL 

NSN  7540-01-280-5500 


Standard  Form  298  (Rev.  2-89) 
Prescribed  by  ANSI  Std.  239-18  298-102 


1 


11 


Approved  for  public  release;  distribution  is  unlimited 


VIDEO  CONFERENCING  USING  PACKET  RADIO  TECHNOLOGY 

Narongchai  Nimitbunanan 
Second  Lieutenant,  Royal  Thai  Air  Force 
B.S.,  U.S.  Air  Force  Academy,  1995 

Submitted  in  partial  fulfillment  of  the 
requirements  for  the  degree  of 


MASTER  OF  SCIENCE  IN  SYSTEMS  ENGINEERING 


from  the 


NAVAL  POSTGRADUATE  SCHOOL 
June  1997 


Frederic  H.  Levien,  Chairman 
Information  Warfare  Academic  Group 


iii 


iv 


ABSTRACT 


Information  and  its  effective  delivering  means  are  becoming  more  and  more 
important  in  today’s  vi^orld.  Video-conferencing  is  a  highly  effective  means  to  deliver 
information  since  it  is  interactive.  This  thesis  studies  the  packet-radio-networking 
technology  that  can  be  used  to  support  video-conferencing  applications.  The  popular 
networking  protocols,  i.e.  the  Amateur  X.25  (AX.25),  the  Transport  Control  Protocol/ 
Internet  Protocol  (TCP/IP),  and  other  protocols,  widely  used  in  packet  radio  technology  are 
described.  By  using  the  File  Transfer  Protocol  (FTP)  of  the  TCP/IP  standard,  the  average 
speed  and  time  of  various  file  sizes  across  a  half-duplex  radio  channel,  a  full-duplex 
emulated-radio  channel,  and  a  RS-232  link  were  collected  and  analyzed.  Finally, 
comparisons  were  made  among  channels,  including  the  effects  of  an  additional  routing 
node. 
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I.  INTRODUCTION 


A.  PROJECT  OVERVIEW 

Information  is  becoming  more  and  more  important  in  the  modem  days’  day-to- 
day  activities,  whether  they  be  civilian  activities  or  military  activities.  The  means  to 
deliver  information  has  evolved  rapidly  over  the  past  years.  It  is  true  that  information 
superiority  is  becoming  another  important  pillar  of  any  combat  type  of  operations. 

Hence,  there  is  a  need  for  better  means  of  delivering  vital  information  effectively, 
reliably,  and  on-time,  because  these  can  result  in  life  or  death  in  combat  situations. 
Traditionally,  information  is  mostly  delivered  over  voice/audio  type  of  systems,  in  real¬ 
time  or  near  real-time.  However,  ‘a  picture  is  worth  a  thousand  words’  as  an  old  Chinese 
saying,  hence,  it  may  be  beneficial  to  find  a  better  mean  to  deliver  essential  information 
both  in  traditional  voice/audio  and  in  life-interactive- video,  in  a  real-time,  or  near  real¬ 
time  mode. 

In  a  shipboard  situation,  such  as  in  a  battle  group  where  there  are  many  ships 
traveling  together  in  an  open  sea.  The  live-interactive-video  conferencing  may  be  very 
useful  in  communicating  with  each  other  among  various  ships.  Combat  effectiveness 
and/or  logistic  support  activities  may  be  improved  by  implementing  this  type  of  system 
as  a  mean  to  deliver  effective,  reliable,  on-time,  and  secure  information  among  ships  in 
the  same  battle  group  or  to  a  different  group  nearby.  The  system  studied  here  is  the 
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packet  radio  network,  which  can  be  used  as  a  backbone  or  as  a  medium  to  deliver  the 
information  among  ships.  The  system  will  have  a  number  of  nodes  or  routers  installed 
on  each  ship.  And,  the  information  would  be  sent  out  by  a  source,  which  may  be  one  of 
many  ships  in  the  battle  group,  and  then  would  be  routed  through  these  nodes/routers 
installed  on  the  ships,  from  ship-to-ship  until  it  reaches  the  desired  destination.  However, 
the  implementations  of  this  system  is  not  only  restricted  to  a  sea-based  platforms  but  can 
also  be  implemented  on  lands  where  many  nodes/routers  are  installed  on  the  vehicles, 
which  may  be  either  moving  or  stationary. 

B.  INTRODUCTION 

Since  our  objective  is  to  conduct  video  conferencing  over  a  packet  radio  network 
in  an  economic  way,  there  are  two  important  issues  we  need  to  consider.  First  is  what 
type  of  hardware/software  we  need  to  capture,  encode/decode,  and  display  acceptable 
video-quality  images.  And,  second  is  what  type  of  networking  supports  we  need  as  a 
medium  to  deliver  the  data.  A  practical  and  economic  way  to  deal  with  the  first  issue  is 
to  utilize  the  Desk-Top- Video-Conferencing  (DTVC)  technology  due  to  its  low-cost  and 
availability  in  today’s  market.  A  good  source  for  DTVC  software/hardware  vendors  is 
listed  by  C.E.  Hendricks  and  J.P.  Steer  [17].  There  are  many  available  commercial 
hardware/software  packages  in  today’s  market  such  as  Cu-SeeMe,  Picture  Tel, 

Connectrix,  VideoLabs,  and  etc.  But,  to  deal  with  the  second  issue,  which  is  the  focus  in 
our  study,  we  need  to  find  out  what  type  of  radio  networks  and  supports  needed  to 
accomplish  our  objective. 
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For  flexibility  and  compatibility  with  the  industrial  standards  and  today’s  markets, 
our  system  is  intended  to  support  the  Transport  Control  Protocol/Intemet  Protocol 
(TCP/IP)  in  many  networking  environments  such  as  the  Wide  Area  Network  (WAN), 
Local  Area  Network  (LAN),  the  Internet,  and  the  Packet  Radio  Networks,  etc.  The 
implementations  of  our  system  will  probably  be  in  a  packet-switching  type  of  networks. 

In  1994,  J.  Haiju,  V.P.  Kosonen,  and  C.  Li  studied  the  quality  and  performance  of  DTVC 
technology  in  the  interconnected  LANs  environments  with  TCP/IP  carriers  [18].  The 
team  found  out  that  there  is  a  slight  degradation  in  video  quality  with  increasing  number 
of  nodes  and/or  switches.  However,  our  study  only  focus  on  the  effects  of  one 
node/router  positioned  between  links  with  the  TCP/IP  protocol  riding  over  another 
protocol  i.e.  the  Amateur  X.25  protocol  (AX.25).  The  AX.25  protocol  is  widely  used  in 
the  Amateur  Packet  Radio  Networks  and  has  many  good  features  to  support  delivery  of 
data  over  a  radio-networking  scheme.  Also,  during  1995,  C.P.  Bandy,  D.B.  Koch  did 
some  experiments  on  transmitting  stilled  images  over  a  low-bandwidth  transmission 
system  [9].  Their  system  emulated  a  packet-radio  transmission  by  using  telephone 
modems.  The  system  demonstrated  promising  results  for  delivering  quality  stilled  images 
over  a  low-bandwidth  channel.  In  our  experiments,  however,  we  actually  transmit  data 
packets  over  a  real  half-duplex  packet-radio  channel,  and  also  over  a  emulated  full-duplex 
radio  channel. 

There  are  a  couple  of  reasons  which  make  this  project  very  interesting;  the 
flexibility  of  the  system  and  the  possibility  of  a  practical  video-conferencing  system  at  a 
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very  low-cost.  This  project  will  require  little  or  no  development  cost  at  all,  since  all  the 
technologies,  both  hardware  and  software  components,  are  already  available  at  low  costs 
in  today’s  market.  The  intended  system  would  use  mostly  Commercial-off-the-Shelf 
products  with  little  or  no  software  modifications  to  suit  the  needs. 

C.  GOALS 

The  overall  goal  of  this  project  is  to  study  a  prototype  system  which  may  be  used 
to  implement  an  interactive  video-conferencing  application  by  using  a  packet  radio 
networking  scheme.  The  long-term  goal  is  to  incorporate  commercially  available  video- 
conferencing  software/hardware  to  our  packet-radio  networking  backbone.  The  video- 
conferencing  software/hardware  components  should  support  standard  protocols  such  as 
Serial-Line-Interface  Protocol  (SLIP),  TCP  /IP,  Point-to-Point  Protocol  (PPP),  and  etc. 
Hence,  we  should  be  able  to  incorporate  these  components  in  some  kind  of  a  Network- 
Operating-System  (NOS)  software  which  will  be  used  to  run  on  the  nodes/router. 

However,  the  scope  of  the  study  in  this  paper  is  only  to  investigate  the 
capabilities,  possibilities  ,  and  limitations  of  various  components  and  transmission 
mediums  required  to  support  such  a  system.  Hence,  the  initial  study  explained  in  this 
thesis  is  limited  to  only  study  the  behaviors  of  the  data  being  transmitted  through  the 
amateur  radio  channel  (i.e.  the  440-MHz  UHF  band).  The  amateur  packet  radio  utilizes 
the  AX.25  protocol,  and  the  existing  TCP/IP  networks  implemented  through  the  directly 
connected  RS-232  line.  In  addition,  routing  behavior  of  the  packets  through  both 
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channels  are  studied  because  the  overall  goal  of  this  continuing  project  is  to  conduct 
video-conferencing  over  the  hybrid  networks  i.e.  the  packet-radio  networks  and  the 
existing  conventional  TCP/IP  networks  (or  other  wired  networks). 

D.  APPROACH 

The  approach  used  in  this  study  is  to  study  the  channel’s  data  transmission 
behavior  by  sending  some  data  using  a  packet-radio  protocol  between  various  nodes 
connected  by  various  types  of  mediums  i.e.  the  RS-232  line,  the  radio  half-duplex 
channel,  and  the  radio  full-duplex  channel.  First,  the  data  packets  are  sent  through  the 
UHF  radio  channel  with  a  maximum  speed  of  19.2  K-baud.  Then,  the  channel  is 
improved  by  emulating  it  as  a  full-duplex  radio  channel.  With  an  emulated  channel,  to 
study  the  routing  effects,  the  data  packets  are  routed  through  both  the  link,  a  RS-232  line 
connected  between  the  two  nodes  running  under  a  Network  Operating  System  (NOS),  and 
the  emulated-radio  full-duplex  channel.  The  application  protocol  used  in  this 
experiments  is  the  File-Transfer-Protocol  (FTP).  Various  file  sizes  are  created  and  sent 
through  the  channels.  Then,  the  performance  parameters,  i.e.  the  time  in  seconds  and  the 
average  speed  in  Bytes/second  for  each  file  transfer  operation,  are  recorded.  All  the 
networking  nodes  in  our  experiments  are  running  under  the  Tampa  Network  Operating 
System  (TNOS),  which  is  just  a  version  the  original  KA9Q  Network  Operating  System 
(KA9Q  NOS),  written  by  Phil  Kam  [6]. 
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This  thesis  is  organized  into  six  major  chapters.  The  first  chapter.  Chapter  I, 
describes  the  project  in  a  big  picture,  including  approach  used  and  objectives  of  our 
studies.  Chapter  II  gives  the  readers  some  backgrounds  needed  to  understand 
fundamental  technologies  in  this  field;  the  packet  radio  and  networking.  Chapter  IE 
explains  the  experimental  set  ups,  used  in  our  study.  Then,  the  results  are  explained  in 
Chapter  IV.  Chapter  V  discusses  the  results  and  compare  them  with  other  experiments. 
Lastly,  Chapter  VI  concludes  the  experiments  and  recommends  future  research  efforts. 
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II.  BACKGROUND 


A.  PACKET  RADIO  BACKGROUND 

Amateur  Packet  Radio  is  an  on-going  development  technology  in  the  amateur 
radio  world.  Both  the  software  and  hardware  are  currently  being  developed  and  tested  by 
the  amateur  packet  radio  enthusiasts. 

1.  History  of  Packet  Radio 

The  data  packet  technology  was  developed  and  put  into  practical  use  during 
1960’s  with  the  ARPANET  project  [1].  However,  the  amateur  world  of  packet  radio  did 
not  benefit  from  the  development  of  this  technology  until  during  the  1970’s.  The  first 
amateur  packet  radio  operations  began  in  Montreal,  Cadana,  and  followed  by  the 
Vancouver  Amateur  Digital  Communication  Group  (VADCG)  [1]. 

In  today’s  radio  mateur  world,  for  some  simple  reasons;  practicalities  and 
economics,  the  packet  radio  technology  is  increasingly  becoming  popular.  Packet  radio 
contains  wide  varieties  of  applications  for  amateur  radio  broadcast  ranging  from  near 
real-time  converse  mode,  remote  telnet,  file  transfer  service  (FTP),  simple  mail  transfer 
protocol  (SMTP),  or  even,  transferring  stilled  images  in  a  near  real-time  environment. 
These  applications  are  possible  because  this  type  of  technology,  through  a  ‘free’  amateur 
radio  band,  is  able  to  provide  flexibility  and  capabilities  of  conventional  digital 
communication  networking  at  an  incredibly  low-cost. 
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For  an  example,  an  amateur  packet-radio  operator  can  sent  the  information 
through  the  amateur  radio  network  to  a  node  at  may  be  2500  miles  away  with  little 
investment  in  the  equipment.  The  minimum  components  of  the  equipment  to  conduct 
such  operations  are  the  terminal  node  controller  (TNC),  a  computer  or  a  terminal,  and  a 
2-meter  transceiver.  These  equipments  are  already  available  in  the  market  at  low  costs. 
In  this  experiment,  the  PC  computers  under  DOS  are  already  available,  hence,  the  only 
additional  equipments  needed  are,  the  TNC,  the  transceiver,  and  the  software  to  transmit 
radio  signals  in  a  network  environments. 

Further  more,  there  are  still  a  few  more  reasons  that  make  packet  radio  more  and 
more  popular;  transparency,  error  correction,  and  automatic  control  [1].  Transparency  is 
provided  by  the  packet  radio  technology  to  the  end  users.  Each  user  make  a  connection  to 
the  other  station,  then  the  data  input  by  the  user  will  be  sent  to  appear  at  the  destination 
node  automatically.  This  is  done  by  the  Terminal  Node  Controller  (TNC).  The  TNC 
receives  input  data  through  the  interface  from  the  data  input  terminal  i.e.  the  computer 
running  a  software  packet,  or  a  dum  terminal,  then,  it  automatically  divides  the  data  into 
packets  and  put  the  overheads  onto  each  packet  (usually  an  AX.25  protocol  overheads). 
The  TNC,  then,  keys  up  the  transmitter  and  send  the  packets  through  the  radio  wave 
carriers  i.e.  UEnFA^HF,  or  microwave,  etc. 

In  additions,  the  TNC  hardware  also  provides  automatic  error  detection  scheme. 

If  the  information  is  corrupted  during  transmission  through  the  medium,  it  will 
automatically  send  a  request  for  retransmission  to  the  transmitter.  Hence,  only  correct 
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data  are  received,  stored,  and  displayed  to  the  operator.  A  typical  packet  radio  station 
with  various  components  and  interfaces  are  shown  in  Figure  1  below. 
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Figure  1:  A  Packet  Radio  Station  [1] 

One  of  the  packet-radio  features  that  makes  the  technology  very  interesting  is  that 
it  has  a  shared  channel  capability  [1].  This  means  that  many  users  can  share  the  same  RF 
channel  at  the  same  time.  This  capability  is  possible  because  of  the  utilization  of  a 
special  protocol  designed  for  amateur  packet  radio  called  the  AX.25  protocol  (the 
Amateur  X.25  protocol).  The  AX.25  protocol  identifies  the  channel  accessibility  by 
using  the  TNG  to  sense  if  any  station  is  transmitting,  and,  if  it  is  so  ,  it  will  wait  until  the 
channel  is  free.  This  scheme  is  called  the  CSMA  or  ‘Carrier  Sense  Multiple  Access’. 

2.  The  AX.25  Protocol 

The  AX.25  protocol,  or  the  Amateur  X.25  protocol,  was  developed  based  on  the 
conventional  X.25  protocol,  used  widely  in  the  wired  network.  The  X.25  protocol  is 
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modified  due  to  its  own  lacking  of  some  necessary  features  which  are  needed  in  the 
wireless  radio  types  of  operations.  The  AX.25  adds  a  digipeater  field  for  extended  range 
by  other  stations  repeating  the  packets  over  and  over  again  until  the  packets  reach  the 
destination  [1],  Also,  the  AX.25  protocol’s  packet  format  adds  the  sender’s  callsign  and 
the  receiver’s  callsign  to  every  packet,  which  is  very  useful  for  identification  purposes 
[1]. 

The  AX.25  is  a  link-layer  protocol  that  is  able  to  support  various  types  of 
communication  links.  According  to  the  OSI  model  [3],  the  AX.25  link-layer  is  just  right 
above  the  physical  layer,  hence,  it  is  independent  of  higher  level  and  can  support  many 
communication  schemes  regardless  of  the  existence  of  many  other  higher  levels  [2].  The 
independence  of  its  link  layer  from  higher-level  layers  is  because  it  already  have 
capabilities  for  reliable  transfer  of  information  across  the  physical  link  layer  i.e. 
synchronization,  error  control,  and  flow  control.  These  capabilities  are  minimiim 
requirements  for  establishing  a  link  and  are  providing  the  amateur  radio  operator  with  a  lot 
of  flexibility  due  to  small  overhead  losses  required  by  higher-layer  OSI  models.  Typical 
implementation  of  the  OSI  model  is  as  shown  in  Figure  2. 


10 


Application  Layer 

AX.25  Link  Layer 

Application  Layer 

Presentation  Layer 

Presentation  Layer 

Session  Layer 

Session  Layer 

Transport  Layer 

Transport  Layer 

Network  Layer 

Network  Layer 

Data  Link  Layer 

Data  Link  Layer 

Radio  Link 

Physical  Layer 

Physical  Layer 

Figure  2  :  The  OSI  Model  [3] 

This  protocol,  the  AX.25,  also  follows  the  recommendations  of  the  Consultative 
Committee  on  International  Telegraphy  and  Telephony  X.25  (CCITT  X.25)  [3],  but  it  is 
different  in  the  extended  address  field,  designed  to  support  operations  in  a  radio 
environment  [2],  In  addition,  the  AX.25  also  adds  an  Unnumbered  Information  frame 
i.e.  a  UI  frame.  The  shared-RF  channel  is  also  implemented  in  the  AX.25  protocol, 
following  the  CCITT  recommendation  Q.921,  supported  by  the  distinguished  and 
extended  address  field  [2]. 

The  improved  features  of  the  AX.25  protocol  allow  the  protocol  to  support  more 
than  one  link  layer  per  communication  device,  provided  that  the  device  is  able  to  handle 
more  than  one  link  establishment,  and  also  allows  the  protocol  to  be  able  to  operate  well 
in  either  ‘half-duplex’  or  ‘full-duplex’  radio  environments  [2]. 
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Once  the  data  from  the  higher  level  are  processed  and  sent  to  the  lower  level 

I 

before  passing  it  to  the  physical  level  (i.e.  the  link  layer),  the  data  are  divided  into  small 
blocks  of  information  called  ‘frames’,  which  are  composed  of  various  smaller  subsections 
called  ‘fields’.  There  are  typically  three  types  used  by  the  AX.25  protocol;  the 
Unnumbered  frame  (the  U  frame) ,  the  Information  frame  (the  I  frame),  and  the 
Supervisory  frame  (the  S  frame).  The  constmctions  of  the  three  types  of  frames  are 

i 

j 

shown  in  Figure  3. 
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Figure  3:  The  U,  S,  and  I  Frame  Formats  [2] 

From  the  above  frame  formats,  there  are  many  field  types  inside  the  frames,  and 
each  is  responding  to  specific  function.  The  flag  field  is  8-bit  or  1  octet  long  and  has  a 
unique  specific  bit  sequence  -  ‘01111110’  (or,  7E  Hex.).  This  specific  bit  sequence  is 
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put  at  the  beginning  and  the  end  of  a  frame  to  indicate  that  the  information  between  the 
two  flags  is  some  kind  of  a  frame.  Hence,  this  unique  bit  sequence  cannot  appear 
anywhere  else  except  in  the  flag  fields.  The  mechanism  that  guarantee  the  non¬ 
reappearance  of  the  unique  flag  bit  sequence  is  called  the  ‘bit  stuffing’  operations.  Bit 
stuffing  is  done  by  monitoring  the  transmitted  frame  to  see  if  there  is  any  five  I’s  in 
sequence,  if  there  is,  then  a  ‘0’  bit  is  stuffed  right  after  the  five  ‘  1  ’  sequence.  And,  at  the 
receiving  DXE,  it  will  utilize  the  same  mechanism  to  monitor  the  frame’s  bit  sequence, 
but,  this  time,  instead  of  adding  another  ‘O’,  it  will  discard  any  ‘0’  bit  right  after  the  five 
consecutive  ‘  1  ’  sequence.  This  operation  guarantees  that  there  will  not  be  any  flag  field 
pattern  appearing  anywhere  inside  the  frame  which  may  cause  confusion  and  errors  to  the 
receiving  DXE.  After  the  beginning  flag  field,  there  is  an  address  field  which  contains 
two  sub-fields  indicating  both  the  source  and  destination  addresses  of  the  specific  frame. 
In  additions,  if  there  are  repeaters  for  the  purpose  of  extended  range  along  the  way 
between  the  source  and  destination,  the  addresses  of  the  repeaters  are  also  encoded  into 
the  address  field.  Once,  the  frame  reaches  the  destination,  it  may  be  interrupted  by 
various  sources  of  interference  along  the  path,  which  may  cause  the  frame  errors.  Hence, 
the  AX.25  protocol  provides  mechanisms  for  error  checking  in  the  PCS  field.  The  PCS, 
or  the  Prame  Check  Sum  field  contains  a  16-bit  sequence,  and  is  calculated  by  both  the 
receiver  and  the  transmitter.  The  identical  PCS  fields  on  both  ends  indicate  that  there  are 
no  error,  otherwise  the  frame  is  corrupted  by  the  medium  if  the  PCS  fields  are  not 
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matched.  In  this  case,  the  receiver  may  discard  the  error  frame  and  send  a  request  for 
retransmission. 

The  other  field  inside  the  frame  which  is  very  important  is  the  control  field.  It  is 
used  to  identify  what  type  of  frame  it  is  i.e.  either  the  U-frame,  the  I-frame,  or  the  S- 
frame.  The  Information-Transfer  frame,  or  the  I-Frame,  is  responsible  for  transferring  of 
the  actual  data  contained  in  its  information  field  [2].  To  identify  all  the  I-frame  from 
other  types,  the  bit  #  O’s  in  its  control  field  is  set  to  zero.  The  I-frame’s  control  field  also 
contains  the  sender’s  send  sequence  number,  N(S),  which  is  the  send  sequence  number  of 
the  current  frame.  This  number  is  updated  just  right  before  the  frame  is  being 
transmitted.  The  sender’s  device  has  an  internal  send  state  variable  to  keep  track  of  the 
next  sequential  number  of  the  next  frame  which  is  to  be  transmitted.  And,  this  internal 
variable  is  used  for  updating  the  send  sequence  number  prior  to  transmitting  the  frame. 
The  I-frame’s  control  field  is  encoded  as  follows. 


Control  Bit  Sequence  Number 


7 

. 

1 

N(R.) 

P 

N(S) 

0 

Figure  4  :  The  I-Frame’s  Control  Field  Format  [2] 
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The  N(R.)  is  the  received  sequence  number  which  exists  in  both  the  I-Frame  and 
the  S-Frame.  This  number  implies  the  complete  and  proper  operations  of  the  received 
frames  up  to  the  N(R.)  -1  frame.  Also,  same  as  updating  the  N(S),  the  N(R.)  is  also 
updated  accordingly  to  the  device’s  internal  received  state  variable,  in  which,  the  variable 
contains  the  next  expected  number  of  the  incoming  frame.  The  P-bit  is  actually  the  P/F  bit 
(Poll  or  Final  Operations).  The  Poll  mode  is  used  to  request  an  immediate  reply  to  a 
frame,  and,  the  reply  to  this  specific  frame  is  done  by  resetting  the  Poll  bit  to  a  Final  bit. 

Other  than  the  I-frame,  the  S-frame  is  also  playing  an  important  role  in 
establishing  and  maintaining  the  links.  The  S-frame  provides  many  valuable  services 
such  as  acknowledging,  requesting  retransmission  in  case  of  errors  ,  and  providing  link- 
level  window  control  [2].  The  S-frame  is  distinguished  from  others  by  setting  bit  #  0  of 
the  control  field  to  one,  and  bit  #  1  to  zero.  In  the  S-frame’ s  control  field,  there  are  a  few 
encoding  mechanisms  which  are  really  important  in  its  operations;  they  are  RR,  RNR, 
and  REJ.  The  RR  is  ‘Receiver  Ready’  used  to  indicate  that  the  sender  of  the  RR  is  ready 
to  receiver  more  I  frames.  It  also  implies  that  the  frames  up  to  N(R.)  -1  is  properly 
received  and  acknowledged.  The  RNR  is  ‘Receiver  Not  Ready’,  in  contrast  to  the  RR,  it 
is  used  to  indicate  that  the  sender’s  device  is  busy  and  not  being  able  to  receive  more  I 
frames  at  that  time.  And  also,  the  I  frames  which  are  indexed  higher  than  N(R.)  - 1  may 
be  lost  or  unacknowledged.  The  REJ  is  ‘Reject  Frame’  which  is  used  to  indicate  that  the 
frame  may  be  duplicated  or  is  out  of  sequence,  and  it  is  rejected  by  the  receiver.  The 
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REJ  is  also,  at  the  same  time,  used  to  request  retransmission  of  the  frames  starting  with 
the  frame  indexed  with  N(R.)  and  above. 

Another  interesting  frame  format  used  for  the  AX.25  protocol  is  the  Unnumbered 
frame  format  (the  U-frame).  This  type  of  frame  allows  more  control  of  the  link  in 
additions  to  the  typical  Supervisory  frame  (S-frame).  The  U-frame  is  also  responsible  for 
establishing  and  terminating  the  link  connections,  and  it  also  allows  some  other  unusual 
flow  operations  [2].  The  U-frame’ s  control  field  is  used  to  indicate  either  the  frame  is  a 
command  or  response  frame.  There  are  six  important  encoding  schemes  for  its  control 
field  formats,  they  are  the  SABM,  DISC,  DM,  UA,  FRMR,  and  the  UI. 

The  SABM  is  the  ‘Set  Asynchronous  Balanced  Mode’  command.  It  is  used  to  set  both 
DXE’s  into  an  asynchronous  balanced  mode  [2].  In  the  shared-RF  channel  with  the 
AX.25  protocol,  the  DXE  is  used  to  replace  both  the  master  device  i.e.  the  DCE  ,  or  the 
Data  Communicate  Equipment  and  the  slave  device  i.e.  the  DTE,  or  the  Data  Terminal 
Equipment.  This  is  because  the  AX.25  treats  both  devices  as  equal  importance,  not 
unequal  as  in  the  classical  master/slave  scenario  for  the  typical  unbalanced  mode  of 
operations.  To  accept  the  SABM  request  and  confirm  the  setting  of  an  asynchronous 
balanced  mode,  the  DXE  must  issue  the  UA  (Unnumbered  Acknowledge)  at  the  earliest 
opportunity.  Once  the  link  is  established,  if  any  DXE  wants  to  terminate  the  link,  it,  then, 
has  to  issue  the  DISC  command  (the  Disconnect  Command),  and  wait  for  the  UA 
response  from  the  other  DXE  before  it  enters  the  disconnect  state.  When  the  received 
frame  cannot  be  processed  and  the  retransmission  of  that  specific  frame  will  not  solve  the 
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problem,  the  DXE  will  response  by  sending  the  FRMR  (Frame  Reject  Response)  to  the 
sender  containing  the  information  field  that  indicates  the  cause  of  rejection.  This  scenario 
usually  occurs  when  the  received  frame  does  not  contain  the  FCS  (Frame-Check-Sum) 
field,  or  from  many  other  causes.  In  some  cases,  one  of  the  DXE  may  try  to  send  other 
frames  other  than  the  SABM  or  the  UI  while  they  are  in  the  disconnected  mode.  Then, 
the  DXE  will  response  to  the  sender  with  the  DM  (the  Disconnected  Mode)  response 
telling  the  other  DXE  that  it  is  still  in  the  disconnected  mode  and  also  requesting  a  set 
mode  command.  Another  case  that  the  DXE  issues  the  DM  response  is  when  it  receives 
the  SABM  mode  and  is  not  yet  being  able  to  establish  a  connection  at  this  time. 

There  are  some  cases  when  the  DXE  wants  to  send  frames  bypassing  the  link 
layer  ‘s  normal  information  flow  control.  The  UI  (Unnumbered  Information)  frame 
allows  the  DXE  to  do  just  that.  The  UI  frame  contains  the  PID  (Protocol  Identifier)  and 
the  information  field  which  is  independent  of  normal  flow  control,  and,  hence,  it  can  be 
passed  back  and  forth  freely  [2].  But,  since  the  UI  frames  are  unnumbered  and  above  the 
normal  flow  control,  they  will  not  be  acknowledged  by  the  receiving  DXE,  this  causes 
unrecoverable  UI  frames  when  lost.  However,  the  UI  frame  can  request  an  indirect 
acknowledgment  by  setting  its  P-bit  to  ‘1’.  The  set  P-bit  causes  the  receiving  DXE  to 
response  with  a  DM  frame  while  in  the  disconnected  mode  and  with  either  a  RR  or  a 
RNR  frame  while  in  the  information  transferring  state. 
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B.  PACKET  RADIO  NETWORKING 


1.  Network  Operating  System  (NOS) 

Packet  radio  technology  is  a  way  to  send  information  in  some  sort  of  packet 
format,  which  encapsulates  data  with  protocols  and  source/destination  addresses, 
including  some  information  regarding  the  path  along  the  way.  The  real  benefit  of  packet 
radio  technology  is  that  the  information  can  be  send  to  the  destination  by  using  a 
networking  scheme,  giving  the  operators  more  flexibility,  efficiency,  and  effectiveness  in 
delivering  the  information.  The  software  package  that  supports  the  implementations  of 
packet  radio  technology  in  a  networking  scheme  is  called  the  Network  Operating  System 
(NOS).  There  are  many  Network-Operating-System  (NOS)  software  packages  available 
today  to  support  the  implementations  of  this  kind  of  technology  such  as  the  NET/ROM, 
KA9Q  NOS  ,  WNOS,  JNOS,  and  TNOS,  etc.  However,  many  of  the  software  packages 
are  based  on  the  original  KA9Q  NOS,  written  by  Phil  Kam  [6],  but  with  some 
modifications  and  enhancements.  The  main  attraction  for  the  NOS  is  that  it  supports  an 
internationally  agreed  standard,  which  gives  it  the  ability  to  operate  in  many  existing 
networks  and  interfaces  such  as  the  packet  radio  networks,  the  telephone  lines,  the  Local 
Area  Networks,  and  the  TCP/IP  networks  (i.e.  the  Internet)  [5].  This  makes  the  NOS  as 
a  very  powerful  communication  tool  because  information  can  be  routed  in  both  the 
conventional  wired-networks  and  the  more  flexible  radio-networks. 
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The  flexibility  of  the  NOS  comes  from  its  supports  of  many  protocols  such  as  the 
ARMPnet  (the  Amateur  TCP/IP  Packet  Radio  Networks),  NET/ROM,  and  the  AX.25. 
The  packet  format  is  as  shown  in  Figure  5. 


'  AX^ 
i.iHeadcsr 

•NET/ROM  '  ; 
He^er 

Header 

TCP 
,  H(^r 

'  '.DATA  •  ' 

Figure  5  :  NOS  Multi-Protocol  Frame  Format  [5] 

From  the  format  above,  hence,  there  are  at  least  three  routing  schemes 
possible  by  the  NOS;  AX.25  routing,  NET/ROM  routing,  and  TCP/IP  routing.  The  NOS 
has  commands  to  set  up  routing  for  these  protocols.  The  ‘ax25  route  add’  command  can 
be  used  to  set  up  a  digipeater  routing  scheme,  which  will  be  explained  later.  The 
NET/ROM  and  the  TCP/IP  routing  schemes  can  be  accomplished  by  the  NOS  commands 
‘netrom  route’  and  ‘route’  [5]. 

2.  Networking  Schemes 

As  mentioned  earlier,  packet  radio  is  flexible  and  very  useful  because  the 
information  can  be  efficiently  routed  through  various  networks  to  reach  the  desired 
destinations.  There  are  many  networking  schemes  used  in  packet  radio  technologies 
such  as  the  digipeaters,  KA-nodes,  NET/ROM,  ROSE,  TCP/IP,  and  the  TexNet  [1].  A 
digipeater  is  simply  a  repeater.  It  is  only  used  to  extend  the  range  of  the  packets  by  re¬ 
transmitting  any  packet  that  is  addressed  to  itself  to  the  next  digipeater,  if  any,  or  to  the 
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destination  node.  The  downfall  of  the  digipeaters  is  that  the  source  station  has  to  wait  for 
the  acknowledgment  from  the  final  destination  node.  If  there  are  many  digipeaters  along 
the  path,  it  may  waste  precious  time.  One  improvement  is  made  over  this  scheme  by 
allowing  each  digipeater  to  be  able  to  acknowledge  the  received  packet,  hence,  the 
acknowledge  is  executed  at  each  link  instead  of  the  whole  path.  This  makes  the  transfer 
of  information  a  llittle  more  robust  than  just  a  simple  digipeater  scheme.  This  scheme  is 
called  the  ‘KA-nodes’  type  of  operations. 

a.  NET/ROM 

The  first  two  schemes,  mentioned  earlier,  are  not  really  a  real  networking 
type  of  operations.  The  first  attempt  to  set  up  a  networking  scheme  is  by  using  a  local 
station  connected  to  the  user,  then,  the  local  station  can  connect  the  user  to  the  others 
through  that  local  station.  And,  if  the  destination  is  out  of  the  local  range,  then,  the 
NET/ROM  local  station  will  try  to  make  a  connection  to  another  local  station  nearby 
again  and  then  again,  if  necessary,  until  it  can  reach  the  desired  destination.  The  local 
station,  in  this  case,  is  called  the  NET/ROM  station.  The  NET/ROM  is  a  firmware  i.e. 
the  software  installed  on  a  chip  [1],  which  is  responsible  for  routing  and  making 
necessary  connections.  This  method  makes  the  information  transfer  more  efficient  since 
each  user  is  only  connected  to  its  own  local  station  instead  of  connecting  to  a  distant 
destination. 
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b. 


ROSE 


Another  routing  scheme  other  the  NET/ROM,  ROSE  uses  a  static  routing 
table  [1].  The  ROSE  protocol  maintains  a  static  list  of  nodes  that  it  can  reach.  And,  if 
any  user  wants  to  utilize  the  list  maintained  by  the  ROSE  switches  along  the  way,  then, 
he  or  she  must  specify  the  addresses  of  the  ROSE  switches  in  their  digipeater  fields  until 
the  packets  can  reach  the  other  user  maintained  by  a  final  ROSE  switch.  The  trade-offs 
between  the  NET/ROM  automatic  routing  scheme  and  the  ROSE’s  static  routing  scheme 
is  the  reliability  and  maintenance.  The  ROSE  protocol  is  more  reliable  because  each 
node  maintain  a  specific  list  that  it  can  reach  for  sure,  unlike  the  NET/ROM  which  may 
try  to  reach  an  reachable  node.  However,  the  NET/ROM  can  update  its  list  automatically 
as  a  new  node  makes  a  contact  with  the  NET/ROM  station,  without  having  to  manually 
update  the  routing  list.  But,  when  conditions  change  and  some  nodes  which  are  no 
longer  reachable,  the  NET/ROM  station  will  falsely  still  maintain  those  nodes  as 
reachable  ones. 

c.  TCP/IP 

Another  popular  protocol  is  the  TCP/IP  protocol  (Transport  Control 
Protocol/Intemet  Protocol)  which  is  supported  by  the  various  packet  radio  technologies 
such  as  the  original  KA9Q  NOS  (KA9Q  Network  Operating  System),  JNOS,  and  the 
TNOS  (Tampa  Network  Operating  System).  The  TCP/IP  allows  flexibility  and 
compatibility  in  routing  the  packets  through  various  existing  networks.  Also,  there  are 
many  facilities  already  existed  in  the  TCP/IP  protocol  such  as  FTP,  Telnet,  SMTP 
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(Simple  Mail  Transfer  Protocol),  and  NNTP  (Net  News  Transfer  Protocol),  etc.  The 
implementation  of  TCP/EP  routing  scheme  into  the  amateur  packet  radio  world  is  by 
having  the  AX.25  rides  on  the  top  of  the  TCP/IP  protocol. 

When  the  AX.25  is  integrated  with  the  TCP/IP  networks,  the  NOS 
supports  such  integration  by  using  the  TCP/IP  links  as  a  wormhole  to  route  information. 
The  command  that  is  supported  by  the  NOS  to  do  the  wormhole  routing  is  the  ‘AXIP’ 
command  which  implies  ‘AX.25  over  IP  networks’.  This  command  can  also  be  used 
with  the  ‘attach’  command  to  make  the  NOS  recognizing  the  interface.  The  ‘attach  axip 
. . .  ’  command  creates  a  RFC  1226  compatible  AX.25  frame  encapsulator  for  transmission 
of  the  AX.25  frames  over  the  internet  [6],  which  makes  the  IP  wormhole  routing 
possible.  The  AX.25  wormhole  routing  over  IP  networking  scheme  is  shown  in  Figure  6. 
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Figure  6  :  AX.25  over  TCP/IP  Links  [5] 
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III.  EXPERIMENTAL  SET-UPS 


Since  it  is  desirable  to  study  some  data-transfer  characteristics  and  performance 
over  different  channels.  A  test  bed  with  a  radio  channel  was  set  up  in  the  laboratory. 
Hence,  several  communicating  nodes  were  set  up  with  various  communicating 
mediums  between  them.  Firstly,  we  want  to  study  the  data-transfer  behaviors  over  a 
simple  radio  channel.  Two  nodes  connected  with  a  half-duplex  radio  medium  were 
used.  Secondly,  we  want  to  improve  the  performance  of  the  data-transfer  measured 
from  the  first  set-up,  so,  an  emulated  full-duplex  radio  channel  with  optimum  allowable 
hardware  configurations  was  used.  And,  thirdly,  we  want  to  study  the  routing  effects 
across  the  node,  so,  we  incorporated  an  additional  node  and  perform  data-transfer 
operations  across  the  router.  However,  some  specific  hardware  and  software 
components  needed  to  be  correctly  configured  and  interfaced  are  described  here. 

A.  THE  TNOS  SOFTWARE 

1.  An  Introduction  to  TNOS 

TNOS,  or  the  Tampa  Networking  Operating  System,  is  a  multi-threaded  program 
that  is  able  to  handle  the  TCP/IP  standard  protocol  in  a  radio  environment,  and,  was 
written  by  Brian  A.  Lantz  [4].  The  software  was  developed  from  the  original  version 
KA9Q  NOS,  and,  has  many  foundations  and  many  features  alike,  but,  with  additional 
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enhancements.  To  make  the  explanations  simple,  we  will  be  referring  to  NOS  instead  of 
the  TNOS  because  NOS  is  more  general  and  original. 

NOS  is  a  complex  software  package  that  supports  most  of  the  widely  used 
communication  protocols  over  the  internet  such  as  the  TCP/IP,  TELNET,  FTP,  SMTP, 
and  over  the  packet  radio  network  such  as  AX.25,  NET/ROM,  and  PBBS  mail  [5].  The 
NOS  can  act  as  a  gateway,  a  router,  or  simply  a  digipeater,  and  is  platform-independent, 
which  means  that  all  these  protocols  can  run  on  any  operating  system  such  as  the  PC, 
UNIX/XENIX,  DEC  VAX  on  VMS,  or  a  Sparc  workstation  on  SunOS,  etc.  [5].  Since  it 
has  an  internal  multitasking  operating  system,  the  software  package  can  act 
simultaneously  as  a  client,  a  server,  and  a  switch  for  the  three  set  of  the  protocols  i.e.  the 
TCP/IP,  AX.25,  and  the  NET/ROM  [6].  This  means  that  while  the  local  user  is 
accessing  other  systems  through  the  network,  other  users  in  the  network  can  also, 
simultaneously,  utilize  the  local  system’s  resources  [6]. 

2.  Installing  the  TNOS 

In  our  experiments,  the  TNOS  is  running  on  a  PC  platform,  under  Windows  95  or 
Windows  3.1 1.  The  reason  that  we  run  the  TNOS.EXE  under  Windows  3.11  and 
Windows  95  is  because  the  software  needs  a  DPMI  (DOS  Protected  Mode  Interface), 
which  already  exists  under  the  Microsoft  Windows  3. 1 1  &  95  [7].  The  DPMI  is  needed 
because  it  has  capabilities  to  collaborate  between  the  multitaskers  and  other  Protected 
mode  utilities  [7].  The  TNC  is  interfaced  to  the  PC  through  a  serial  port  i.e.  the 
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asynchronous  COM  ports;  COM1-COM4.  The  TNC  is  operating  in  a  KISS  mode  which 
means  that  it  simply  passes  all  the  information  from  radio  to  be  processed  by  the  TNOS 
software  package  inside  the  PC.  The  overall  picture  is  as  shown  in  Figure  7. 
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Personal  Computer 
(PC) 
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(TNC) 
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Transmitter/Receive 


Figure  7  :  The  TNOS  Software  Interfaces  [5] 


The  TNOS  software  package  is  distributed  freely  through  various  internet  sites 
such  as  at  the  ‘ftp://ftp.lantz.com/tnos/current’  or  at  the  ‘ftp.ucsd.edu’  in  the 
‘/hamradio/packet/tcpip’  directory  [4].  There  are  a  couple  of  files  needed  to  be 
downloaded;  the  base  supported  file  and  the  execution  file  (TNOS.EXE).  The  supported 
file  is  in  a  ‘.ZIP’  format,  and  it  can  be  decompressed  by  using  a  free  unzip  shareware,  i.e. 
the  PKUNZIP.EXE  with  the  ‘-d’  option,  which  will  put  all  the  decompressed  files  into 
their  corresponding  directories.  Once  the  TNOS.EXE  file  is  downloaded  into  a  platform 
i.e.  a  PC  in  our  set  up,  then,  its  autoexec.nos  is  needed  to  be  configured  to  meet  specific 
needs  for  each  user.  When  the  TNOS.EXE  is  running,  at  first,  it  will  automatically  look 
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for  the  ‘autoexec.nos’  file  which  should  contain  all  the  configuration  information  needed 
for  operating  the  network  correctly.  And,  if  the  file  does  not  exist,  the  user,  then,  has  to 
input  the  detailed  configurations  manually  line-by-line  during  the  executing  program. 
The  example  of  the  autoexec.nos  is  given  in  Appendix  A. 

3.  I/O  Device  Interfacing 

There  are  some  important  configurations  needed  to  be  carefully  set  up  before  we 
can  operate  the  software  correctly  for  our  data-transfer  experiments;  these  are  the  ‘attach’ 
command,  the  ‘ftpusers’  file,  and  the  ‘domain.txf  file,  etc.  These  files  are  also  given  in 
Appendix  A. 

In  our  experiments  we  want  to  utilize  the  FTP  session  supported  in  the  TNOS 
software  to  transfer  the  files  of  various  sizes,  and  then  study  the  file  transfer 
characteristics  through  various  channels  and  environmental  settings.  To  accomplish  this 
purpose,  the  TNOS  software  must  be  able  to  interface  with  the  PC’s  I/O  devices  through 
their  corresponding  device  drivers.  In  our  case,  we  use  the  PC’s  asynchronous  COM 
ports  as  our  I/O  devices.  The  TNOS  software  package  can  acknowledge  the  COM  ports 
through  its  ‘attach’  command.  The  attach  command  allows  the  TNOS  software  to 
interface  to  various  hardware  device  drivers  such  as  the  asynchronous  COM  ports,  the 
Ethernet,  and  the  Modem,  etc.  [6].  The  attach  command  loads  up  the  specific  device 
driver  through  its  corresponding  device’s  I/O  port  address.  Hence,  the  attach  command 
will  need  to  know  the  COM  port’s  base  I/O  address,  including  its  interrupt  request  level 
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(IRQ),  the  desired  protocol  to  be  used  through  that  specific  COM  port,  and  some  other 
important  parameters  such  as  the  buffer  size  and  the  packet  length. 

4.  Setting  Up  the  FTP  Session 

Another  important  set-up  before  we  can  utilize  the  FTP  protocol  in  our 
experiments  is  the  ‘ftpusers’  file.  Once  the  TNOS  software  is  correctly  installed,  this  file 
is  under  the  ‘../etc/’  directory.  It  maintains  the  allowed  list  of  user  names  and  their 
corresponding  passwords,  including  their  allowed  directories  and  types  of  operations  i.e. 
‘read  files’,  ‘create  new  files’,  or  ‘write/delete  existing  files’  [5].  Also,  given  a  domain 
name,  and  the  user  is  trying  to  make  a  connection  to  another  station,  the  software  will 
need  to  know  the  IP  address  of  such  station.  TNOS  deals  with  this  matter  by  having  a 
look-up  table  to  translate  the  desired  domain  names  into  their  corresponding  IP  addresses 
contained  in  the  ‘domain.txt’  file  which  can  either  be  automatically  updated,  by  the 
software  itself,  or,  manually  updated,  by  the  user.  Once  the  software  is  installed,  this  file 
is  under  the  ‘../spool/’  directory. 

5.  Setting  the  TNC  Parameters 

In  our  experiments,  the  TNC  is  needed  to  be  set  into  the  KISS  mode.  The  TNOS 
has  the  ‘comm’  command  that  is  able  to  set  up  the  TNC  to  do  such  thing.  Before 
switching  the  TNC  into  a  KISS  mode,  to  prevent  unrecognized  parameter-settings,  the 
TNC  should  be  reset  into  its  default  values  before  changing  other  parameters  to  other 
settings.  The  string  ‘reset’,  sent  directly  from  TNOS  to  the  TNC,  will  result  in  resetting 
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the  TNC.  The  command  that  is  able  to  send  strings  directly  to  the  TNC  is  the  ‘comm’ 
command,  i.e.  the  communication  command.  To  switch  the  TNC  into  the  KISS  mode, 
the  strings  ‘int  kiss’,  i.e.  meaning  ‘interface  kiss’,  must  be  sent  to  the  TNC. 

Other  than  the  ‘comm’  command,  there  is  another  command  that  is  able  to 
communicate  directly  with  the  TNC  and  set  the  TNC’s  parameters  to  different  settings. 
The  TNC  parameter  settings  can  be  changed  by  executing  the  ‘param’  command,  i.e.  the 
parameter  command.  The  TNC’s  TXDELAY,  PERPIST,  SLOTTIME,  and  many  other 
parameters  can  be  set  by  using  this  command. 

In  our  experiments,  the  TNC  is  operating  under  a  KISS  mode  (Keep-It-Simple- 
Stupid  Mode).  The  frame  format  at  each  interface  is  shown  in  Figure  8. 


TNC  Port  Number 


Control  Code 


/ 


Figure  8  :  The  KISS  Frame  Format  [5] 
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As  shown  by  the  in  Figure  8,  the  KISS  TNC  simply  passes  all  the  data  to  the  PC 
through  the  asynchronous  port  for  the  data  to  be  processed  at  a  higher  level  [5].  Hence, 
the  TNC  is  only  responsible  for  the  RF  channel  access  and  frame  conversion.  The  TNC 
controls  the  RF  channel  access  properties  by  settings  its  two  parameters;  the  ‘PERSIST’ 
and  the  ‘SLOTTIME’.  The  RF  channel  is  accessible  when  the  TNC  does  not  detect  any 
carrier  on  the  air.  Then,  it  will  start  a  timer  with  the  length  of  time  specified  by  the  user 
through  the  ‘SLOTTIME’  parameter.  Once,  the  timer  is  out,  then,  the  TNC  will  generate 
a  random  number  between  0  -  255.  The  random  result  will  be  compared  with  the  user’s 
specified  ‘PERSIST’  parameter.  If  the  generated  random  number  is  less  than  or  equal  to 
the  user’s  setting  PERSIST  value,  it  will  then  key  up  the  transmitter  and  transmitter  the 
packets  out  over  the  channel.  For  frame  conversion,  the  TNC  simply  puts  or  strips  off  the 
frame’s  start  &  finish  characters  i.e.  the  ‘FEND’  characters.  All  the  decisions  regarding 
routing,  access  permission,  digipeating  and  all  other  higher  level  protocols  are  made  at  a 
higher  level  in  TNOS,  not  at  the  TNC  level. 

B.  THE  HARDWARE 

1.  The  Terminal  Node  Controller  (TNC)  &  The  D4-10  Transceiver 

The  Terminal  Node  Controller  (TNC)  and  radio  used  in  our  experiments  are  the 
Katronics  Data  Engine  and  a  10-  watts  high-speed  transceiver  i.e.  the  D4-10  UHF  Wide- 
Band  Transceiver  [19].  The  transceiver  operates  in  a  high-speed  packet  radio  mode  on 
the  UHF  band  (430.55  MHz).  When  combining  the  D4-10  transceiver  with  the 
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Katronics  Data  Engine,  there  are  two  possible  speeds;  the  9600  baud  rate  or  the  19200 
baud  rate  [19].  The  Data  Engine  has  an  internal  DE19K2/9K6  modem  which  is  capable 
of  generate  the  ‘data  carrier  detected  (CD)’  signal  from  the  received  data  stream,  and  is 
very  useful  for  many  of  its  operations  [19]. 

There  are  quite  a  few  fundamental  mechanisms  concerning  radio  operations  which 
needed  to  be  well  understood  before  we  can  operate  the  radio  channel  efficiently;  the 
‘Push-To-Talk’,  the  ‘TXDELAY’,  and  the  ‘Carrier  Detected  (CD)’.  In  general,  when  a 
typical  HAM  radio  operator  wants  to  transmit  a  radio  signal,  the  operator  must  push  the 
transmitter  button  and  then  talk.  This  operation  is  called  the  ‘Push-to-Talk’  operation, 
and  is  executed  whenever  the  operator  wants  to  modulate  the  data  and  transmit  the  signal 
over  a  radio  channel.  However,  before  the  signal  is  transmitted  in  the  form  of  a  radio 
wave  through  the  air,  the  transmitter  must  be  fully  powered-up  to  its  maximum  power 
setting  to  achieve  its  maximum  signal  strength.  The  time  delay  during  powering-up  the 
transmitter  is  called  the  transmitting  delay  (TXDELAY).  Once,  the  signal  is  transmitted 
and  is  arriving  at  a  receiver,  the  receiver  will  have  some  delay-time,  called  the  ‘Squelch 
Time’  [19],  before  it  acknowledges  the  presence  of  the  received  signal  and,  then, 
produces  a  CD  signal.  This  delay-time  should  also  be  accounted  for  in  the  TXDELAY 
setting.  Once,  the  signal  is  detected,  then  the  CD  will  be  pulled-down  low  by  the 
transceiver  and  output  to  the  TNC  to  start  demodulating  the  signal  [19].  However,  the 
CD  may  be  generated  by  the  firmware  inside  the  TNC  instead,  which  is  a  feature  in  all  the 
Katronics  Data  Engines  [19]. 
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As  mentioned  earlier,  the  TNC  in  our  experiments,  operates  in  a  KISS  mode 
which  allows  all  the  higher-level  protocols  to  be  processed  in  the  TNOS  software. 
However,  some  hardware  parameters  inside  the  TNC  must  be  optimally  set  up  to  achieve 
a  maximum  performance.  These  hardware  parameters  are  the  TXDELAY, 
PERSISTENCE,  SLOTTIME,  modem  (half  or  full-duplex),  and  KISS  [19].  Setting 
these  parameters  can  largely  affect  the  data-transfer  performance  of  the  RE  channel. 
Generally,  the  smaller  the  TXDELAY,  the  better  the  performance  due  to  less  wait-time 
for  the  sender  before  keying-up  its  transmitter.  Also,  the  larger  the  PERSIST  value,  the 
faster  the  data  transfer  because  there  is  more  chance  for  the  sender  to  key  up  the 
transmitter.  However,  the  receiver’s  buffers  may  be  flooded,  if  the  PERSIST  value  is  set 
too  high  because  the  resceiver  and  its  corresponding  Central-Processing-Unit  (CPU)  may 
not  be  able  to  process  the  received  data  fast  enough.  Hence,  there  may  be  some  lost 
characters  due  to  overflowing  the  buffers.  The  lost  characters  will  cause  transmission 
errors  and  requesting  for  retransmission.  The  effect  of  data  retransmission  is  negative  to 
the  data  transfer  performance  of  the  channel. 

Another  important  hardware  parameter  setting  is  the  SLOTTIME.  The 
SLOTTIME  is  the  time  period  between  the  PERSIST  algorithms  to  generate  a  random 
number.  The  SLOTTEME  should  be  long  enough  to  allow  the  packets  to  be  processed  at 
both  ends  i.e.  the  transmitter  and  the  receiver,  including  the  round-trip-estimated  time  on 
both  ends.  Again,  intuitively,  the  smaller  the  SLOTTIME,  the  more  frequently  the 
transmitter  makes  its  decisions  whether  it  wants  to  transmit  the  packets  or  not  (by 
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generating  a  random  number  and  compare  with  the  setting  PERSIST  value).  And, 
further  more,  there  is  another  TNC  hardware  parameter  setting,  called  the  ‘modem’,  that 
can  be  set  to  enhance  performance  of  the  data  transfer  process  over  a  radio  channel  by 
setting  at  full-duplex.  If  the  FULLDUP  is  turned  on,  then  the  TNC  will  operate  in  a  full- 
duplex  mode.  It  means  that,  between  the  two  communicating  nodes,  they  will  not  have  to 
wait  for  the  channel  to  be  free  before  anyone  of  them  can  transmit  or  receive 
acknowledgment  data  since  they  both  have  different  channel  of  their  own.  Unlike 
operations  in  the  half-duplex  environments,  with  full-duplex  environments  both 
communicating  nodes  can  transmit  and  receive  data  at  the  same  time,  which  really 
improves  the  performance  of  the  data  transfer.  In  real  life,  for  a  full-duplex  radio,  there 
may  be  two  frequencies  needed  for  such  operations.  Also,  when  the  operator  wants  the 
TNC  to  process  some  low-level  protocols  supported  by  its  built-in  firmware,  not  as  just  a 
dum  hardware  passing  all  the  information  to  the  TNOS  at  a  higher  level,  the  TNC  can  be 
commanded  to  exit  out  of  a  KISS  mode  by  using  the  ‘KISS’  command. 

2.  The  PC  and  its  FIFO 

The  three  PC’s  used  in  our  experiments  are  IBM  compatible  with  various  Intel 
CPU’s;  the  66-Mhz  486DX,  200-Mhz  Pentium™,  and  the  75-Mhz  Pentium.  The  two 
PC’s  with  the  Intel  66-Mhz  486DX  CPU  and  the  200-Mhz  Pentium™  CPU  are  running 
under  Windows  95.  These  two  PC’s,  in  our  experiments,  are  named  PC  #  1  and  PC  #  2, 
consequently.  The  other  PC  with  the  Intel  75-Mhz  Pentium  CPU  is  running  under 
Windows  3. 1 1,  which  is  named  PC  #  3  in  our  experiments. 
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There  is  a  very  important  issue  in  putting  various  PC’s  together  to  work  in  a 
networking  environment  through  their  asynchronous  I/O  devices  s  i.e.  modem  and  serial 
interfaces,  which  is  the  buffer  size  supported  by  the  UART  chip  at  their  corresponding 
FIFO’s  ( First-In-First-Out  buffer).  The  UART  is  an  abbreviation  for  ‘Universal 
Asynchronous  Receiver/Transmitter’  [7].  The  buffer  mismatch  may  result  in  difficulties 
in  transferring  data  through  the  asynchronous  device  due  to  lost  data. 

The  performance  of  the  UART  chips  depend  on  how  fast  they  reset  after  an 
interrupt  request  for  data  transfer  from  the  CPU.  The  original  National  Semiconductor 
8250  chip,  with  a  1-byte  buffer,  resets  in  1000  ns.  [7],  which  is  good  enough  in  the  old 
days  where  the  CPU  was  not  as  fast  as  today.  If  the  UART  chip  does  not  reset  before  the 
next  CPU’s  interrupt  request,  there  may  be  problems.  However,  with  faster  and  faster 
CPU  in  today’s  market,  the  UART  must  have  much  faster  reset  time  to  satisfy  the  CPU’s 
interrupt  speed.  The  UART  chip  store  data  on  in  its  buffer  and  wait  for  the  CPU’s 
interrupts  to  transfer  data.  The  newer  16450  UART  chip,  also  with  1-byte  buffer,  has 
some  speed  improvement  -  200  ns.  reset  time  [7].  This  helps  out  a  lot  when  working 
with  faster  CPU  such  as  the  486  CPU  and  later.  But,  again,  the  new  problems  occur  with 
increasing  multitasking  environments,  such  as  those  running  under  Windows  3.11  and 
Windows  95,  and,  with  higher  performance  (i.e.  speed)  of  data  transfer  device  -  9.6 
Kbaud  rate  and  19.2  Kbaud  rate,  etc.  The  problems  originate  when  the  1-byte  buffer  is 
full  and  the  UART  chip  is  not  able  to  transfer  data  to  the  CPU  at  that  time  because  the 
CPU  is  processing  other  task  (i.e.  multitasking  environment),  and  there  is  more  data 
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coming.  Hence,  the  UART  chip  may  be  forced  to  discard  the  data,  which,  in  our 
experiments,  may  cause  some  lost  characters  and  requests  for  data  retransmission.  The 
overall  result  is  a  slower  speed  for  the  FTP  operation. 

However,  the  newer  UART  chip,  the  16550  chip,  solves  this  problem  by  adding 
more  buffers  to  store  data  to  be  transferred  at  later  time.  The  16550  UART  chip  has  a 
16-byte  buffer,  which  can  be  set  to  any  size  between  1  16-byte  size  in  the  software 
(under  Windows  95  in  our  experiments).  But,  the  interfacing  between  these  PC’s  with 
different  buffer  sizes  is  a  problem  because  the  1-byte  buffer  may  be  overflowed  and, 
hence,  causes  lost  characters.  In  our  experiments,  PC  #  1  has  a  8250  UART  chip,  and 
both  PC  #  2  and  PC  #  3  have  16550AF  UART  chips.  We  solved  the  buffer  mismatch 
problem  by  setting  the  16550AF  UART  chip  to  operate  with  only  1-byte  buffer  for  both 
receiving  and  transmitting.  This  1-byte  buffer  setting  works  well  and  solves  the  buffer- 
overflowed  problem  in  our  experiments.  The  TNOS  software  provides  a  mean  to  check 
the  asynchronous  device  status  through  the  ‘asystat’  command.  By  using  this  command, 
if  there  is  a  buffer-overflowed  situation,  then,  the  number  of  lost  characters  will  show  up 
under  the  display  ‘hw  over’  i.e.  meaning  ‘hardware  overflow’. 

3.  Hardware  Interfaces  &  Low  Level  Protocols 

NOS  (including  TNOS)  supports  many  interfacing  devices  such  as  serial  ports 
(COM1-COM4),  Modem  Control,  Ethernet  Adapters,  Clarkson  Drivers,  PACcom  PCIOO, 
DRSI PCPA  8530  driver.  High  Speed  DRSI/HAPN  driver.  Semi-port  and  Multi-port 
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KISS  TNC,  and  etc.  [5].  Also,  there  are  a  number  of  protocols  supported  by  NOS  to 
interface  with  such  devices;  for  examples,  the  KISS  protocol  for  TNC  control,  the  ST  TP 
protocol  and  the  PPP  protocol  for  serial-link  point-to-point  telephone  links,  the  NRS 
protocol  for  NET/ROM  control,  and  the  Ethernet  and  ARCnet  protocols  for  Ethernet 
adapters. 

The  SLIP  (Serial-Link-Intemet-Protocol)  protocol  can  be  used  between  a  poit-to- 
point  type  of  operations.  The  SLIP  does  not  need  a  link  header  since  the  connection  is 
only  point-to-point.  The  IP  datagrams  are  simply  encapsulated  with  the  SLIP  frames 
[6].  Also,  another  useful  protocol,  used  for  Point-to-Point  links,  is  the  PPP  protocol.  The 
PPP  encapsulates  the  datagrams  in  an  HDLC-like  frame,  which  is  an  Internet  standard 
that  is  compatible  with  the  CCITT  (Consulative  Committee  in  International  Telegraphy 
and  Telephony)  standards  [3,6].  HDLC  is  an  abbreviation  for  ‘High-level  data  link 
control’,  specified  by  the  ISO  3309, 4335  [3].  The  HDLC  frame  contains,  consequently; 
an  8-bits  flag  field,  ‘at  least’  1 -octet  address  field,  8-  or  16-bits  control  field,  variable- 
length  information  field,  16-  or  32-bits  Frame-Check-Sequence  (FCS),  and  again,  lastly, 
the  8-bits  flag  field. 

In  our  experiments,  we  use  the  KISS-mode  TNC  to  interface  with  the  PC  using 
the  AX.25  protocol  to  communicate  with  the  other  nodes.  Also,  we  interface  the  two 
PC’s  together  by  using  the  AX.25  protocol  over  the  asynchronous  I/O  devices. 
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IV.  RESULTS 


Since  we  want  to  study  some  data-transfer  characteristics  and  performance  over 
various  channels,  including  their  interactions  with  a  radio  channel,  hence,  there  are  some 
communication  nodes  needed  to  be  set  up  with  the  desired  mediums  between  them. 
Firstly,  to  study  the  data-transfer  behaviors  over  a  radio  channel,  we  set  up  two  nodes 
connecting  with  a  half-duplex  radio  medium.  Secondly,  to  improve  the  performance  of 
the  data-transfer  from  the  first  set-up,  an  emulated  full-duplex  radio  channel  with 
optimum  allowable  hardware  configurations  was  used.  And,  thirdly,  to  study  the  routing 
effects  across  the  node,  so,  we  incorporated  an  additional  node  and  performed  data- 
transfer  operations  across  the  router. 

A.  DATA  PACKETS 

By  using  the  ‘trace’  command,  the  data  packets  can  be  seen  and  recorded  for  later 
analysis.  The  ‘trace’  command  enable  the  software  to  trace  all  the  packets  passing 
through  the  asynchronous  I/O  device  (i.e.  at  the  local  COM  port).  The  maximum 
transfer  unit  (MTU),  a  hardware  dependent  parameter,  used  for  the  data  packets  in  our 
experiments  is  a  512-bytes  size  (specified  by  the  attach  command).  Hence,  each  packet 
will  have  472  bytes  of  data  at  the  TCP  level,  because  the  TCP/IP  cost  an  overhead  of  40 
bytes.  The  level  hierarchy  from  higher-to-lower  levels  are  TCP  level  IP  level 
AX.25  level  ->  KISS  level,  as  shown  in  Figure  9. 
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IP:  1 
TCP: 
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0020 
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r 


Kpr  16  17:02:22  1997  -  mxO  «ent : 

:  Port  0  Daca 

:  NPS1->MPS2  UI  pid-IP  fOxccJ 

len  512  44 . 1 , 1 .  l->44 . 1 . 1 . 2  Ihl  20  ttl  254  proc  TCP 
20->1025  Se<5  xUOofOOl  Xck.  x3e60c00l  ACK  Wnd  2046  Data  <72 
9c  «0  «€  €4  40  40  ®0  9c  «0  a6  £2  40  40  6l  03  cc  .  4rde«' .  6b6ea.L 

45  00  02  00  00  Sd  00  00  f«  06  €0  96  2c  01  01  01  E _ I-  -.' . 

2c  01  01  02  00  14  04  01  fa  Oc  fO  01  3e  60  cO  01  . *.p  >'fi 

50.  10  08  00  56  66  00  00  2a  2a  2a  2a  2a  2a  2a  2a  P...Xf.. . 

2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  . 

2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  . 

2a  2a  2a  2a  2a  2a  2a  2a'2a  2a  2a  2a  2a  2a  2a  2a  . . . . 

2a  2a  2a  Od  Oa  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  . 

2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  . . . 

2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  . . 

2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  . . . 

Od  Oa  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2e  2a  2a  2a  . . 

2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2e  2a  . 

2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  . 

2a  2a  2a  2a  2a  2a  2a  2e  2a  2a  2a  2a  2a  Od  Oa  2a  . . . 

2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  . 

2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  . . . 

2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a 

2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  Od  Oa  2a  2a  2a  2a  . . 

2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  . 

2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  . . . 

2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a 

2a  2a  2a  2a  2a  2a  2a  Od  Oa  2a  2a  2a  2a  2a  2a  2a  . . . . 

2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a 

2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  . . 

2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2«  . 

2a  2a  2a  2a  Od  Oa  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  . 

2a  2e  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  . . . 

2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2*  2a  2a  2a  2a  . 

2a  2a  2a  24  2a  2a  2a  24  2a  2a  2a  2a  2a  2a  2a  2a  . 

2a  Od  Oa  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  . . 

2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  . . 

2a  2a  2a  2a  2a  24  2a  2a  2a  2a  2a  2a  3a  2a  2a  2a  . 

pr  16  17:02:23  1997  -  axO  recv: 

Port  0  Data 

HPS2->NPS1  UI  pid-IP  (Oxccl 
an  <0  44. 1 . 1 , 2->4<  .  1, 1 . 1  ihl  20  tcl  25<  proc  TCP 
1025->20  Se<j  x3e60c001  Ack  xfaOafldS  ACK  Wnd  2048 

•  ‘bse- .  td^ea  L 

45  00  00  28  00  12  00  00  £e  06  62  b9  2c  01  01  02  £..( _ -.b9 

2c  01  01  01  04  01  00  14  3e  60  cO  01  fa  Oe  fl  d9  >'«  j  ov 

50  10  08  00  5f  70  00  00  P.i-lp!* 


W«d  Apr  16  17:21:49  1997  -  axO  r«cv: 

KISS:  Pert  0  Data 

AX2S:  HPS1->KPS2  UI  pld-IP  (Oxcc) 

IP:  Ian  512  44.1.1.1-1.44.1.1.2  ihl  20  ttl 
TCP:  20->1025  S«q  xfaOafOOl  AcJc  x3a60c001 


254  prot  TCP 


0000 

9c 

aO 

a6 

64 

40 

40 

•0 

9c 

aO 

a6 

62 

40 

40 

61 

03 

cc 

0010 

45 

•00 

02 

00 

00 

5d  00 

00 

f« 

06 

60 

96 

2c 

01 

01 

01 

0020 

2c 

01 

01 

02 

00 

14 

04 

G1 

fa 

0« 

£0 

01 

3a 

60 

cO 

01 

0030 

SO 

10 

08 

00 

58 

66 

60 

00 

2a 

3a 

2a 

2a 

2a 

2a 

2a 

2a 

0040 

2a 

2a 

2a 

2a 

2a 

2a 

2a 

2a 

2a 

2a 

2a 

2a 

2a 

2a 

2a 

2a 

OOSO 

2a 

2a 

2a 

3a 

2a 

3a  2a 

2a 

2a 

2a 

2a 

2a 

2a 

2a 

2a 

2a 

0060 

2a 

2a 

2a 

2a 

2a 

3a 

2a 

2a 

2a 

2a 

3a 

2a 

2a 

2a 

2a 

2a 

0070 

2a 

2a 

2a 

Od 

Oa 

2a 

2a 

2a 

2a 

2a 

2a 

2a 

2a 

2a 

2a 

2a 

0080 

2a 

2a 

2a 

2a 

3a 

2a 

2a 

3a 

2a 

2a 

2a 

2a 

2a 

2a 

2a 

2a 

0090 

2a 

2a 

2a 

2a 

2a 

2a 

2a 

2a 

2a 

3a 

2a 

2a 

2a 

2a 

2a 

3a 

OOaO 

2a 

2a 

3a 

3a 

2a 

3a 

2a 

2a 

2a 

3a 

3a 

2a 

2a 

3a 

2a 

2a 

OObO 

Od 

Oa 

2a 

2a 

2a 

2a 

3a 

3a 

2a 

2a 

2a 

2a 

2a 

2a 

2a 

2a 

OOcO 

2a 

3a 

2a 

2a 

3a  2a 

2a 

3a 

2a 

2a 

2a 

2a 

2a 

2a 

2a 

2a 

OOdO 

2a 

2a 

2a 

2a 

2a 

2a 

2a 

2a 

2a 

3a 

2a 

2a 

2a 

2a 

2a 

2a 

OOaO 

2a 

2a 

2a 

2a 

3a 

2a 

2a 

2a 

2a 

2a 

2a 

2a 

3a 

Od 

Oa 

2a 

OOfO 

2a 

2a 

2a 

2a 

3a 

2a 

3a 

2a 

2a 

2a 

2a 

2a 

2a 

2a 

3a 

2a 

0100 

2a 

2a 

2a 

2a 

3a 

2a 

2a 

2a 

2a 

2a 

2a 

2a 

2a 

2a 

2a 

2e 

0110 

2a 

2a 

2a 

2a 

3a 

3a 

2a 

2a 

2a 

2a 

2a 

3a 

2a 

2a 

2a 

2a 

0120 

2a 

2a 

2a 

2a 

3a 

2a 

2a 

2a 

2a 

3a 

Od 

Oa 

2a 

2e 

2a 

2a 

0130 

2a 

3a 

3a 

3a 

2a 

3a 

2a 

3a 

3a 

2a 

2a 

2a 

3a 

2a 

2a 

2a 

0140 

2a 

2a 

3a 

2a 

2a 

2a 

3a 

2a 

2a 

2a 

3a 

2a 

2a 

3a 

2a 

2a 

0150 

2a 

2a 

2a 

2a 

2a 

3a 

2a 

2a 

3a 

2a 

2a 

2a 

2a 

2a 

2a 

2a 

0160 

3a 

3a 

2a 

2a 

2a 

2a 

3a 

Od 

Oa 

3a 

2a 

2a 

2a 

2a 

2a 

2a 

0170 

2a 

2a 

2a 

2a 

2a 

3a 

3a 

2a 

3a 

3a 

2a 

2a 

2a 

2a 

2a 

2a 

0180 

2a 

2a 

2a 

2a 

2a 

2a 

2a 

3a 

2a 

2a 

2a 

2a 

2a 

3a 

2a 

2a 

0190 

2a 

2a 

3a 

2a 

2a 

2a 

2a 

2a 

2a 

2a 

2a 

2a 

3a 

2a 

2a 

2a 

OlaO 

2a 

2a 

2a 

2a 

Od 

Oa 

2a 

2a 

2a 

2a 

2e 

2a 

2a 

2a 

2a 

2a 

OlbO 

2a 

2a 

2a 

2a 

2a 

2a 

2a 

3a 

2a 

2a 

2a 

2a 

2a 

2a 

2a 

2a 

OlcO 

2a 

2a 

2a 

2a 

2a 

2a 

2a 

2a 

3a 

2a 

2a 

3a 

3a 

2a 

2a 

2a 

OldO 

2a 

2a 

2a 

2a 

2a 

3a 

3a 

2a 

2a 

2a 

2a 

2« 

3a 

2a 

2a 

2a 

OlcO 

2a 

Od 

Oa 

2a 

2a 

3a 

2a 

2a 

2a 

2a 

2a 

2a 

2a 

2a 

2a 

2a 

OUO 

2a 

2a 

2a 

2a 

2a 

2a 

2a 

2a 

2a 

2a 

2a 

2a 

2a 

2a 

2a 

2a 

0200 

2a 

2a 

2a 

2a 

3a 

2a 

2a 

2a 

2a 

2a 

2a 

2a 

2d 

2a 

2a 

2a 

<.des 
E. . . .  j 


ack. 


W«d  Apr  16  17:21:49  1997  -  axO  a«nt : 

KISS:  Port  0  Data 

AX2S:  NPS2->MPS1  UI  pid-IP  (Oxcc} 

IP:  len  40  44.1 .1.2->44. 1.1.1  ihl  20  ttl  2S<  prot  TCP 
TCP:  102S*.>20  Se<j  x3«60c001  Ack  x£a0afld9  ACK  Wnd  204  8 
0000  9c  aO  a6  62  <0  40  «0  9c  aO  a6  64  <0  40  61  03  cc 

0010  45  00  00  28  00  12  00  00  fe  06  €2  b9  2c  01  01  02 

0020  2c  01  01  01  04  01  GO  14  3e  60  cO  01  fa  0«  fl  d9 

0030  SO  10  08  00  Sf  70  00  00 


.  td^#a.L 
.-.bS _ 


Figure  9  :  Data  Packet  Transfer 

The  data-packet  transfer  example  is  a  typical  interaction  between  the  sender  and 
the  receiver  whenever  there  is  a  transfer  of  data.  First,  the  data  packet  is  sent  by  the 
sender  through  the  ‘axO’  port  device.  Then,  the  receiver  receives  the  packet  at  its  local 
‘axO’  port  device.  Then,  the  receiver  will  send  an  acknowledgment  to  the  sender  to  allow 
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the  sender  to  continue  to  send  the  next  data  packet.  The  data,  in  our  experiments,  is  a 
series  of  the  string  characters,  coded  as  ‘2a’.  All  the  actual  data  is  displayed  in  16- 
bytes  blocks  numbered  starting  from  0000  0200.  At  the  lowest  level,  i.e.  the  KISS- 

protocol  level  between  the  PC  and  the  TNC,  it  only  maintains  a  port  number  and  a  control 
code  (the  format  is  as  shown  in  Figure  8).  In  our  case,  as  shown  in  Figure  9,  the  KISS 
level  has  a  port  numbered  as  ‘O’.  And,  the  control  code  specifies  a  data  type.  At  the  next 
level,  the  AX.25  level,  it  maintains  only  a  call-sign,  a  type  of  frame  format,  and  a  ‘pid, 
i.e.  a  protocol  identification.  In  our  case,  the  frame  format  is  a  UI  frame,  and,  the  pid  is 
an  IP  (or,  an  internet  protocol),  and  the  call-signs  used  for  source  and  destination  stations 
are  NPSl  and  NPS2,  consequently.  The  IP  level  specifies  the  length  of  the  data  packet, 
512-bytes  long  in  this  case.  This  level  also  specifies  the  IP  addresses  for  both  the  source 
and  destination.  The  UI  frame  is  an  ‘Unnumbered  Information’  frame,  which  allows  the 
frames  to  pass  freely  at  the  AX.25  level,  since  they  are  unnumbered.  And,  this  allows 
the  frames  to  be  processed  at  higher  levels  i.e.  the  TCP/IP  levels. 

Since,  the  UI  frames  are  processed  at  a  higher  level  than  the  AX.25  level,  the  error 
checking  is  done  at  the  TCP  level  in  our  case.  If  there  is  an  error,  then  the  TCP  will 
report  the  error  and  automatically  request  a  retransmission  of  the  error  packet.  And,  until 
it  gets  an  error-free  packet,  it  will  then  send  an  acknowledgment  packet  to  the  transmitter 
to  allow  the  next  sequential  packet  to  be  sent.  Figure  10  is  an  example  of  a  Frame- 
Check-Sum  (FCS)  error  detected  at  the  TCP  level.  The  TCP  level  reports  a  FCS  error. 
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and,  automatically,  request  a  retransmission.  It  then  waits  for  the  same  packet  to  be  re¬ 
sent  and  correctly  received  before  it  sends  an  acknowledgment  packet. 


Tuc  Apr  15  16:03:29  1997  -  ixO  rccv: 
iaSS:PortODau 

AX25:  NPS1->NPS2  U1  pi<J=lP  (Oxcc) 

IP;  Ico  256  44.1. l.l.>44.1. 1.2  ihJ  20  oJ  254  protTCP 

TCP:  20->l027  Scq  x28463b0l  Ackx5i2c7001  ACK  Wnd  204S  Data  215  CHECKSUM 
ERROR  (43) 

0000  9ca0a6  64  40  40c09c»0a6  62  4040  61  03cc  .  &b@@a.L 

0010  45  00  01  00  00  3c  0000  fc  06  61  b5  2c  01  01  01  £...>..~.a5.... 

0020  2c  01  01  02  00  14  04  03  2S  46  3b  01  5a  2c  70  01  _ (F;.Z,p.  J 

0030  50  10  01  00  ab  ff  00  00  2a  2i  2a  2a  2a  2a  2a  2a  ! 

0040  2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a  I 

0050  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  . . 

0060  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  •••*•••••••*•♦•< 

0070  2a2a0d0a2a2a2a2a2a2a2a2a2a2a2a2a  . — 

0080  2a2a2a2a22  2a2a2a2a2a2a2a2a2a2a2a 

0090  2a  2a  2a  2a  2i 2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  . . . 

OOaO  2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a0d  . . . 

0060  Oa2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a  .**•••— . 

OOcO  2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a . . 

OOdO  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a . 

OOcO  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  Od  Oa  2a  2a  . ..*• 

OOfO  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  . . . 

0100  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  . 


PCS 


R  ion 


Tuc  Apr  15  16:03:42  1997  -  axO  rocv: 

KISS:  PonODaLa 

AX25:  KPS1->NPS2  Ul  pid=IP(Oxcc) 

IP;  Icn  256  44.  L I .  I  ->44. 1 . 1 .2  ihl  20  OJ  254  pro  t  TCP 
TCP;  20->1027  Scq  x28463b01  Ack  x5a2c7001  ACK  Wed  2045  Data  216 
0^  9ca0a6  64  40  40c0  9ca0a6  62  4040  6]  03cc  .  &b(|>(aa  L 

0010  45  000100  003f00  00fc066lb42c0l0l01  E  *»  -  a4 
0020  2c  01  01  02  00  M  04  03  28  46  3b  01  5a  2c  7001  (F- £p 

0030  50l00800abff00002a2a2a2a2a2a2a2a  P 

0040  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a . . . 

0050  2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a  . . . . * 

0060  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  . . ♦ 

0070  2a2aOdOa2a2a2a2a2a2a2a2a2a2a2a2a  . . . 

0080  2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a  . . 

0090  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  . . 

OOaO  2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a0d  . . 

OObO  Oa  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  . . . 

OOcO  2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a  . . 

OOdO  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  2a  . . 

OOcO  2a2a2a2a2a2a2a2a2a2a2a2a0d0a2a2a  . . ..•* 

OOfi)  2a  2a  2a 2a 2a 2a 2a  2a 2a  2a 2a 2a 2a 2a 2a 2a  . . . 

0100  2a  2a  2a  2a-2a  2a  22  2a  2a  2a  2a  2a  2a  2a  2a  . . 


K  1  -.S  cl^m  ^  yj  T 
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Figure  10  :  An  FCS  Error 
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In  this  case  the  MTU  is  of  256-byte  size,  when  accounted  for  a  40-bytes  TCP/IP 
overhead,  then  there  should  be  at  least  216  bytes  of  data.  But,  the  first  data  packet,  as 
shown  in  Figure  10,  contains  only  215  bytes  of  the  characters.  Hence,  the  TCP 
reports  a  FCS  error,  and  automatically  requests  for  a  retransmission  for  the  same  packet. 
When  the  packet  is  re-transmitted  and  received  correctly  with  216  bytes  of  data,  as 
shown  at  the  TCP  level  of  the  middle  packet  in  Figure  10,  the  receiver  then  responses 
with  an  acknowledge  to  notify  the  sender  to  proceed  with  the  next  sequential  packet 

B.  EXPERIMENT#!:  HALF-DUPLEX  RADIO  CHANNEL 

To  study  the  data  transfer  behavior  over  a  radio  channel,  the  two  nodes  are  set  up 
as  shown  below.  We  decide  to  use  a  hardware  flow  control  at  the  COM  ports  instead  the 
software  flow  control  because  of  superior  performance.  The  hardware  flow  control  is 
accomplished  by  selecting  the  ‘Hardware  Flow  Control’  option  at  the  COM  ports  and 
setting  the  corresponding  TNC’s  parameters  i.e.  DTR  =  1  &  RTS  =  1  on  an  asynchronous 
(asy.)  line. 

Katronics  D4-10 
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The  TXDELAY  on  the  TNC  is  set  to  20  (x  10-ms  unit  time),  i.e.  200  ms,  to  allow 
enough  time  for  the  radio  to  be  fully  powered  up.  Also,  the  PERSIST  value  is  set  to  be 
127,  which  is  approximately  half  of  a  chance  for  transmitting.  At  this  point,  the  half¬ 
duplex  radio  is  used,  and  the  TNC’s  parameter,  ‘modem’,  must  be  set  to  half  duplex  i.e. 
by  using  the  TNC  command  ‘modem  ,half . 

The  data  was  collected  and  shown  in  Figure  12  to  15.  There  are  16  files  with 
various  sizes  ranging  from  185  bytes,  336  bytes,  612  bytes, ..,  1.884  Mbytes, 
consequently.  Each  consecutive  file  is  roughly  double  the  size  of  the  previous  file.  There 
are  four  trials  needed  to  be  collected  for  each  file  due  to  the  nature  of  a  stochastic- 
transmitting  process  ( which  depends  on  the  setting  PERSIST  value).  Then,  the  averages 
in  both  speed  and  time  of  the  four  trials  are  derived.  The  speed  in  Bytes/second  and 
transfer  time  in  seconds  used  in  the  FTP  operation  are  reported  in  the  system  at  the  end  of 
each  file  transfer  operation. 

The  parameter  settings  for  Experiment  #  1  are  shown  in  Table  1.  In  the  table,  DTS 
is  'Data-Set-Ready'.  RTS  is  'Read-to-Send'.  TXDELAY  is  'Transmission  Delay'. 
PERSIST  is  a  'Persistence'  Value.  SLOTTIME  is  a  'Slot  Time'.  TXTADL  is 
'Transmission  Tail  Time'.  And,  lastly,  FULLDUP  is  'Full  Duplex'. 


42 


PARAMETER 

SETTING 

DTS 

1 

RTS 

1 

TXDELAY 

20 

PERSIST 

127 

SLOTTIME 

10 

TXTAIL 

0 

FULLDUP 

O(off) 

Table  1 :  Exp.  #1  Parameter  Settings 

Once  all  the  parameters  were  set,  the  data  samples  for  both  the  time  transfer  and 
speed  versus  file  sizes  were  collected  and  plotted.  The  transfer  time  versus  file  sizes  are 
shown  in  Figure  12  and  Figure  13.  And,  the  speed  versus  file  sizes  are  shown  in  Figure 
14  and  Figure  15. 
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Transfer  Time  versus  File  Size 


Four  Trials 


0.4.  1.2  4.0  20.a  a9.9  203.3  960.7-  1884.5 

Size  (Kbytes  in  L09  Scale) 


Figure  12  :  Exp.  #  1  Transfer  Time  versus  File  Size 
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Tiin9  Transfar  For  Each  Trial  (Sec.) 


Speed  versus  File  Size 


Four  Trials 


.2  0.6  2.5  9.B  41.5  186.6  529.6  1266.6 

0.4-  1.2  4-.9  20.8  8S.9  283.3  9G0.7  1BS4.S 

File  Size  (Kbytes  in  Log  Scale) 


Figure  14  :  Exp.  #  1  Speed  versus  File  Size 
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Speed  versus  File  Size 
Average 


0.4-  1.2  4.9  20.8  89.9  283.3  960.7  18B4.E 

RIo  Size  {Kbytes  in  Log  Seale) 


Figure  15  :  Exp.  #  1  Average  Speed  versus  File  Size 

In  the  plots,  both  the  X-axis  and  Y-axis  are  in  LOG  scale,  and  the  time  transfer 
shows  linearity  with  respect  to  increasing  file  sizes.  This  is  agreed  with  our  expectation 
because  there  is  a  fixed-size  overhead  associated  with  each  data  packet,  and,  hence,  with 
more  data,  it  should  should  require  more  time  to  transfer  the  file  in  a  linear  fashion.  For 
the  average  speed  curve,  it  seems  that  the  speed  curve  is  saturated  at  some  specific  value 
after  the  file  size  is  larger  than  19.2  Kbytes.  By  taking  the  average  of  the  last  six  data 
samples  of  the  speed  curve,  we  estimated  the  settled  speed  to  be  486.70  bytes/sec. 
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By  observations  of  both  the  transfer  time  and  the  speed  curves,  the  data  points  are 
varied  in  a  noticeable  manner.  This  is  because  the  nature  of  the  stochastic  process 
affected  by  the  setting  of  the  PERSIST  value. 

C.  EXPERIMENT  #2:  HARD-WIRED  FULL  DUPLEX 

To  improve  performance  of  data-transfer  through  the  radio  channel,  the  two 
TNC’s  can  be  set  to  operate  at  a  full-duplex  mode.  This  will  require  two  channels  for  the 
TNG  to  be  able  to  transmit  and  receive  at  the  same  time.  Hence,  the  radio  must  be  able  to 
operate  at  two  different  frequencies,  one  for  receiving  and  the  other  for  transmitting. 
However,  our  radio  does  not  have  such  capabilities.  Therefore,  we  emulated  a  full  duplex 
environment  for  the  two  TNC’s  by  directly  connecting  the  two  TNC’s  together  and 
bypassing  the  radio  transceivers.  This  emulation  gives  us  a  full-duplex  like-radio 
channel,  although  we  do  not  have  a  true  full-duplex  radio  channel.  The  main  difference 
between  a  real  full-duplex  radio  channel  and  our  ‘emulated’  full-duplex  channel  is  the 
radio  wave  interference  which  may  occur  in  the  real  channel.  In  our  experiments,  the 
interference  is  assumed  to  be  minimum,  since  we  operate  in  a  controlled  environment  i.e. 
our  laboratory.  Also,  fading  channel  is  assumed  to  be  very  small,  since  the  distance 
between  the  two  nodes  is  very  short  i.e.  approximately  1  meter.  The  set  up  for  an 
emulated-radio  full-duplex  channel  is  shown  in  Figure  16. 
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PC#2  PC#1 


FULL  DUPLEX  CHANNEL 


Approximately  1 -meter  distance 

Figure  16  :  A  Emulated-Radio  Full  Duplex  Channel 

The  connection  between  the  two  TNC’s  are  made  directly  between  the  two  9-pins 
DB-15  connectors  attached  to  the  two  Katronics  Data  Engines  at  port  #  I’s.  The  hard¬ 
wired  diagram  between  the  two  connectors  is  shown  in  Figure  17. 


Figure  17 :  TNC  Hard- Wired  Connections 

The  parameter  settings  for  Experiment  #  2  are  shown  in  Table  2.  Notice,  the  only 
difference  from  Experiment  #  1  is  the  FULLDUP  set  to  1,  which  enables  the  full-duplex 
channel  between  the  two  TNC’s. 
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PARAMETER 

SETTING 

DTS 

1 

RTS 

1 

TxDelay 

20 

PERSIST 

127 

SLOTTIME 

10 

TXTAIL 

0 

FULLDUP 

0 

Table  2  :  Exp  #  2  Parameter  Settings 

Once  the  all  the  parameters  were  set,  the  data  samples  for  both  the  transfer  time 
and  speed  versus  file  sizes  were  collected  and  plotted.  The  transfer  time  versus  file  sizes 
are  shown  in  Figure  18  and  Figure  19.  And,  the  speed  versus  file  sizes  are  shown  in 
Figure  20  and  Figure  21. 
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Time  Transfer  (seconds  in  Log  Scale) 


Transfer  Time  versus  File  Size 

Four  Trials 
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0.4^  1.a  4.S  20.B  8d.9  233.3  980.7  1384.5 

Size  (Kbytes  in  Lo^  Scale) 


Figure  18  :  Exp  #  2  Transfer  Time  versus  File  Size 
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Transfer  Time  versus  File  Size 
average 


10000: 
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Figure  19 :  Exp  #  2  Average  Time  versus  File  Size 
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Speed  versus  File  Size 

Average 


3ize  <Kbytes  in  Log  Soale) 


Figure  21 :  Exp.  #  2  Average  Speed  versus  File  Size 

From  the  time  transfer  and  speed  curves,  it  seems  that  the  FTP  process  is 
smoother  than  that  in  Experiment  #  1.  This  is  because  the  channel  is  a  hard- wired  full- 
duplex  channel,  in  which,  there  is  very  little  interference  compared  to  the  true  radio 
channel.  For  the  speed  curve,  it  seems  more  clear  than  those  in  Experiment  #  1  that  the 
speed  curve  starts  turning  into  a  saturated  speed  at  roughly  19.2-Kbytes  file  size.  And,  by 
taking  the  average  of  the  last  six  data  samples  of  the  speed  curve,  the  average  saturated 
speed  is  1344.9  Bytes/sec. 
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EXPERIMENT  #3;  ENHANCED  HARD-WIRED  FULL  DUPLEX 


In  Experiment  #  2,  the  channel  is  already  a  full-duplex  channel  but  without  a  real 
radio  transmitter.  Hence,  there  are  some  parameters  that  can  be  set  to  achieve  optimal 
performance;  the  TXDELAY  and  the  PERSIST  value.  The  TXDELAY  can  be  set  to  1 
because  there  is  no  need  to  delay  the  data  before  transmitting  for  powering-up  the 
transceiver,  since  there  is  no  radio  transmitter  needed.  Also,  since  the  channel  is 
relatively  cleaner  than  that  in  Experiment  #  1  due  to  hard-wired  full-duplex  environment, 
hence,  the  PERSIST  value  can  be  set  to  its  maximum  value  (255)  to  maximize  the  chance 
for  transmitting  data,  which  increases  the  data  rate  i.e.  speed.  The  parameter  settings  are 
shown  in  Table  3. 

Once  all  the  parameters  were  set,  the  data  samples  for  both  the  transfer  time  and 
speed  versus  file  sizes  were  collected  and  plotted.  The  transfer  time  versus  file  sizes  are 
shown  in  Figure  22  and  Figure  23.  The  speed  versus  file  sizes  are  shown  in  Figure  24 
and  Figure  25. 
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PARAMETER 


SETTING 


DTS 

1 

RTS 

1 

TxDelay 

1 

PERSIST 

255 

SLOTTIME 

10 

TXTAIL 

0 

FULLDUP 

1 

Table  3  :  Exp.  #  2  Parameter  Settings 
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og  Scale) 


0.2  0.6  2.5  9.8  41.5  186.6  520.6  i  268.6 

0.4  1.2  4.9  20.8  89.9  263.3  960.7  16B4.S 
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Figure  23  :  Exp.  #  3  Average  Time  versus  File  Size 
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Speed  versus  File  Size 


Average 


Sbce  {Kbytes  in  L.c^g|  Scale) 


Figure  25  :  Average  Speed  versus  File  Size 

From  the  time  transfer  and  speed  curves  for  Experiment  #  3,  it  is  clear  that  there  is 
some  speed  improvement  when  optimal  parameters  are  used.  The  average  speed  from  the 
last  six  data  samples  is  1528.25  bytes/sec. 
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E.  EXPERIMENT  #  4:  ROUTING  EFFECTS 

In  additions  to  EXP  #  2,  we  want  to  study  the  effects  of  routing  when  there  are 
more  than  two  nodes  involved.  Hence,  we  make  some  modifications  and  add  a  router, 
PC  #  1 ,  between  PC  #  2  and  PC  #  3  as  shown  in  Figure  26. 


PC#1 


PC#2 
'TNOS  I 

jtlio  ♦ 


RS-232  Line 
(FuH-DupIex  Channel) 


Figure  26  :  Adding  a  Routing  Node 

As  shown  in  Figure  26,  PC  #  1  is  set  up  as  a  router  between  the  two  PC’s.  The 
FTP  operations  are  conducted  between  PC  #  2  and  PC  #  3.  The  files  are  transferred  from 
PC  #  3  to  PC  #  2.  A  route  table  is  created  and  maintained  at  PC  #  1  by  using  the  TNOS’ 
‘route  add’  command. 

An  additional  interface  between  PC  #  2  and  PC  #  1  is  the  RS-232  line,  which  was 
added  to  the  set  up  of  EXP  #  2.  The  RS-232  line  is  an  industry-standard  physical 
interface.  It  is  intended  for  communicating  no  more  than  50  feet  at  20,000  bps  [7]. 
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There  is  an  important  issue  in  dealing  with  the  RS-232  line,  it  is  the  selection  of  the  flow- 
control  scheme.  There  are  two  flow-control  schemes  used  to  prevent  buffer  overflows; 
the  software  flow  control  (XON/XOFF  and  ENQ/ACK) ,  and  the  hardware  flow  control 
(DSR,  CTS,  and  CD)  [7].  The  software  flow  control  is  executed  by  sending  a  ‘STOP’ 
character  back  and  forth  to  notify  the  device  that  the  buffer  is  already  full.  In  contrast,  the 
hardware  flow  control  simply  just  deactivate  the  line  to  prevent/stop  buffer  overflows. 

The  RS-232  link  in  our  experiments  is  implemented  by  using  two  25-pin  connectors.  The 
connection  is  as  shown  in  Figure  27. 


Figure  27  :  RS-232  Line  Connection 
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As  seen  m  Figure  27,  there  are  two  lines  connecting  the  two  end  nodes.  Hence, 
the  RS-232  interface  in  the  above  configuration  is  able  to  transmit  and  receive  data 
simultaneously,  and  so,  acting  like  a  full-duplex  channel.  The  rest  of  the  pins,  not  shown 
in  Figure  27,  are  not  connected,  because  there  is  no  need  to  utilize  them  in  our 
experiments. 

With  optimal  parameters  setting,  another  router  is  added  between  PC  #  2  and  PC  # 
3  as  described  in  the  Experimental  set-up.  The  data  points  were  again  collected  and 
plotted.  The  transfer  time  versus  file  sizes  are  shown  in  Figure  28  and  Figure  29.  The 
speed  versus  file  sizes  are  shown  in  Figure  30  and  Figure  31. 


Transfer  Time  versus  File  Size 
(Routing) 

Four  Trials 
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Time  Transfer  (seconds  in  Log  Scale) 


Transfer  Time  versus  File  Size 
(Routing) 

AVERAGE 


lOQOO; 


1.2  20.a  39.9  2B3.3  900.7  laa^.S 

Slze^  (Kbytes  in  Log  SoaJe) 


Figure  29  :  Exp.  #  4  Average  Time  versus  File  Size 
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Speed  versus  File  Size 
(Routing) 

Average 


0.4  1.2  4.9  20.a  89.9  2B3.3  960.7  1884.5 

Size  (Kbytes  in  Log  Scale) 


Figure  31 :  Exp.  #  4  Average  Speed  versus  File  Size 

The  average  speed  taken  from  the  last  six  data  point,  in  Figure  29,  is  1000.2 
Bytes/sec.  There  is  a  big  drop  in  speed  due  to  routing,  compared  to  previous  average 
speed  curves. 
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V.  DISCUSSION 


A.  TIME  COMPARISON 

The  averages  of  the  four  curves,  time  transfer,  are  plotted  and  compared  as  shown 
in  Figure  32. 


Time  Transfer  versus  File  Size 
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Figure  32  :  Transfer  Time  Comparison 
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Figure  32  compares  the  time-average  curves  used  in  each  experiment.  From  the 
time  comparison  curves  as  shown  in  Figure  32,  the  relative  performance  of  each  curve  is 
related  to  its  own  position  relative  to  others.  For  an  example.  Curve  #  1  (from  Exp.  #  1)  is 
at  a  higher  position  as  compared  to  Curve  #  4  (from  Exp.  #  4),  which  means  that  the 
Curve  #  4  has  a  superior  performance,  since  it  requires  less  time  to  deliver  a  file  of  the 
same  size. 

From  observations  of  the  4  curves,  it  seems  that  they  follow  the  same  trend  even 
though  their  shapes  are  a  little  different.  Curve  #  1  is  a  straight-line  shape  and  different 
from  others  because  it  is  the  only  real  radio  channel.  The  other  curves  show  superior 
performance  than  Curve  #  1  because  they  are  all  full-duplex  channels.  Also,  Curve  #  2, 
Curve  #  3,  and  Curve  #  4  have  similar  shapes  due  to  their  similarities  in  the  experimental 
set-ups.  Curve  #  3  has  the  same  shape  with  Curve  #  2  because  they  both  have  the  same 
set-up.  However,  Curve  #  3  has  a  superior  performance  than  Curve  #  2  because  it  has  an 
optimal  set  of  parameters.  In  addition.  Curve  #  4  has  a  very  similar  shape,  as  compared 
to  Curve  #  2  and  #  3,  this  is  because  Curve  #  4  has  most  of  its  the  set-up  like  of  those 
curves  but  with  an  additional  routing  delay. 

From  comparing  Curve  #  2,  #  3,  and  #  4,  it  seems  that  at  each  region  of  the 
curves,  they  tend  to  follow  a  specific  value  of  local  slope  i.e.  they  almost  have  the  same 
slopes  at  some  local  range  of  file  sizes.  This  local-slope  phenomenal  may  be  a  result  of 
the  window  size  and/or  the  MTU  size,  used  in  our  experiments  with  respect  to  the  file 
size. 
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Speed  (Bytes/sec.  in  Log  Scale) 


B.  SPEED  COMPARISON 


For  speed  comparison  analysis,  the  average  speed  curves  of  Experiment  #  1 
through  Experiment  #  4  are  plotted  in  the  same  graph  to  demonstrate  their  relative 
performance.  The  plot  is  shown  in  Figure  33. 


Speed  versus  File  Size 


Speed  Comparison 


Figure  33  :  Speed  Comparison 


Figure  33  shows  the  speed  comparison  between  the  four  experiments.  In  this 


case,  higher  performance  is  shown  in  a  higher  vertical  position  of  the  curve.  A  higher- 
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curve  position  indicates  a  faster  channel.  And,  as  expected,  like  those  curves  in  Figure 
32,  the  performance  for  each  curve  from  highest-to-lowest  is  Curve  #  3,  Curve  #  2,Curve 
Curve  #  4,  and  Curve  #  1.  The  reasons  are  the  same  as  those  explained  for  Figure  32.  In 
addition,  from  the  observations  of  the  curves,  it  is  clear  that,  in  our  experiments,  the  full- 
duplex  channels.  Curve  #  2,  Curve  #  3,  and  Curve  #  4,  are  superior  in  performance  than  a 
half-duplex  channel.  Curve  #  1. 

Also,  the  turning  comer  before  saturation  of  each  curve  is  close  to  the  number  of 
19.2-Kbytes  file  size.  This  number  is  related  to  our  channel’s  maximum  capacity  of  19.2 
Kbaud  rate  as  provides  by  our  TNC’s.  Before  this  point  on  the  X-axis,  there  is  an 
increase  in  speed  as  the  file  size  is  increasing  until  it  reaches  the  channel  maximum 
capacity  of  19.2  Kbaud.  The  speed  is  increased,  at  the  region  of  small  file  size  below  the 
channel’s  full  capacity,  because  at  those  region  the  data  is  smaller  than  the  pipe  (i.e.  an 
analogy  for  our  channel  capacity).  Hence,  the  more  data  there  is,  the  more  the  channel 
can  deliver.  However,  once  the  data  size  is  larger  than  our  pipe,  then  no  matter  how 
large  our  data  is  we  can  only  put  certain  amount  of  information  into  the  pipe  at  one  time 
because  the  pipe  has  a  fixed  size  (i.e.  as  compared  to  our  channel’s  Baud  rate) .  Hence,  it 
causes  a  speed  saturation  as  shown  in  a  flat  region  on  each  curve. 

In  addition,  from  observing  the  curves  it  is  clear  that  an  additional  routing  node 
tremendously  adds  delay  to  the  speed.  The  increase/decrease  in  performance,  as 
compared  to  each  other,  is  shown  in  Table  4. 
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Experiments 

EXP.#1 

EXP.  #2 

EXP.  #3 

EXP.  #4 

Speed  (Bytes/sec.) 

486.7 

1,344.9 

1,528.25 

1,000.2 

Speed  ( Bits/sec. ) 

3,893.6 

10,759.2 

12,226.0 

8,001.6 

Improvements 

(  X  times  as  Compared  to  Exp.  #  1 ) 

X  1 

X2.76 

x3.14 

x2.05 

Table  4  :  Speed  Comparison 

From  analyzing  Table  4,  it  is  seen  that  the  emulated-radio  full-duplex  channel  as 
in  Exp.  #  2  and  Exp.  #  3  improves  the  speed  by  approximately  3  times  higher  than  that  of 
the  radio  half-duplex  channel  in  Exp.  #  1.  Also,  the  routing  node,  in  Exp.  #  4,  causes  a 
performance  drop  to  only  2.05  times  higher  than  that  of  Exp.  #  1.  Hence,  there  is  a 
tremendous  drop  in  the  performance  due  to  routing. 

Our  maximum  performance  as  shown  in  Exp.  #  3  is  12.226  Kbits/sec.  The  rest  of 
the  bandwidth,  i.e.  6.97  Kbits/sec.,  is  probably  consumed  by  the  overheads,  i.e.  mainly 
the  TCP/IP  &  AX.25,  used  in  transferring  the  data  across  the  mediums.  Hence,  the 
overhead  cost  in  our  experiments  is  relatively  large  compared  to  our  available 
bandwidth. 
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In  a  video-conferencing  application  as  desired  in  our  project,  the  implementation 
may  be  possible  only  if  a  very  effective  compression  scheme  can  tremendously  reduce 
the  size  of  the  data  stream  to  fit  our  maximum  capacity.  It  is  mentioned  in  the  study  by 
[9],  that  a  high  quality  compression  technique  may  be  able  to  compress  the  data  to  below 
1/50  the  size  of  the  original  data.  Assuming  that  this  type  of  compression  scheme  is 
available  and  implemented  with  our  existing  system,  we  would  be  able  to  support  a 
channel  of  more  than  50  x  12.226  Kbits/sec.  (i.e.  61 1  Kbits/sec.). 

With  this  possible  maximum  capacity  of  61 1  Kbits/sec,  we  may  be  able  to  support 
many  image-delivery  implementations  such  as  delivering  a  quality  stilled-image  in  a 
reasonable  time,  as  studies  in  [9],  and,  may  be  in  a  distance  learning  application  as 
studied  in  [14].  In  delivering  a  quality  tilled-image  for  a  medium-quality  image 
resolution  of  the  size  230,400  bytes  [9],  our  system  would  delivery  in  about  151 
seconds,  which  is  an  acceptable  time  for  this  kind  of  application. 

However,  for  a  video-conferencing  type  of  system,  time  of  delivery  is  much  more 
sensitive  than  just  delivering  a  stilled  image.  The  quality  of  video  depends  on  the  frame 
rate  ,  i.e.  number  of  frames  per  second  (fps),  showing  on  the  display.  A  full  broadcast 
television  in  North  America  using  an  NTSC  standard  requires  about  30  fps  [14]. 
However,  this  fps  requires  too  much  bandwidth.  Hence,  many  compression  standards 
are  used  to  tremendously  reduce  the  data  size  to  fit  the  available  bandwidth  for  vedio- 
conferencing  type  of  application  such  as  the  H.221,  H.230,  H.261,  and  H.320,  etc.  [17]. 
Also,  in  the  video-conferencing  type  of  applications,  an  acceptable  video  quality  may  not 
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require  as  high  fps  as  in  a  full  quality  video  (i.e.  it  requires  about  30  fps).  The  minimum 
recommendations,  from  the  study  of  a  distance  learning  type  of  applications  [14],  for  the 
frame  rate  is  6  fps  and  for  the  resolution  needed  is  320x240-pixels.  This  application 
would  require  a  bandwidth  of  375  Kbits/sec  [14].  Hence,  our  system  with  a 
compression  ratio  of  approximately  4: 1  would  be  enough  to  support  such  applications. 
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VI.  CONCLUSION  AND  FUTURE  WORKS 


In  our  experiments,  we  implemented  a  half-duplex  radio  channel  and  performed  a 
data  transfer  performance  study.  We  found  out  that  the  data  rate  was  very  low  and  may 
not  support  video-conferencing  applications.  Hence,  improvements  were  made,  in 
experiments  #  2  and  #  3,  by  using  a  emulated-radio  full-duplex  channel.  The  result  was 
an  increase  in  performance  about  3  times  higher  than  in  experiment  #  1.  Then,  the 
routing  effect  was  studied  by  adding  a  routing  node  between  the  link,  the  effect  was  a 
decrease  in  performance  from  experiments  #  2  and  #  3  down  to  about  2  times  higher  than 
in  experiment  #  1.  From  looking  at  the  data  rate  supported  by  our  system,  it  is  possible 
that,  with  an  advanced  compression  technique,  the  system  will  be  able  to  support  a  video- 
conferencing  type  of  applications  over  a  full-duplex  radio  channel  operating  under  a 
NOS. 

However,  before  a  real  implementation  of  this  type  of  system,  there  are  more 
issues  to  be  studied  such  as  the  security  aspects  of  such  a  system,  the  integration  of  the 
packet-radio-networking  backbone  with  commercial  video-conferencing 
software/hardware  packages.  One  way  to  improve  security,  within  our  experiences  with 
the  TNOS,  is  that  we  may  be  able  to  add  a  secure  encryption/decryption  scheme  to  the 
TNOS  software.  It  is  possible  and  practical  to  download  the  TNOS  software  source  code 
from  the  internet  site  and  add  some  security  mechanisms  to  it  before  recompiling  the 
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modified  source  code.  Also,  the  integration  of  the  video-conferencing  to  the  backbone  is 
possible,  provided  that  they  both  support  the  same  industrial  standards  such  as  the  TCP/IP 
protocol,  or  etc. 
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APPENDIX  A:  CONFIGURATION  FILES 
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#  autoexec. nos  file  for  TNOS  2.20  nps2  01/14/96 

#  By  Narongchai  Nimitbunanan 


#  Specify  Hostname 

#  Local  host's  name.  It  is  used  only  in  the  greeting  messages 

#  of  the  various  network  sservers. 

#  It  DOES  NOT  set  the  system's  IP  address. 

hostname  nps2.ampr.org 

#  Set  the  local  AX.25  address 
ax25  mycall  nps2 

#  Set  thet  default  local  IP  address 
ip  address  44.01.01.02 

#  User 

ax25  user  nps2 

###########  Set  AX25  parameters  MifffffM 

#  AX25  protocal  version  2  which  uses  the  poll/fmal  bits 

#  This  protocal  is  used  when  attempts  to  make  new  connections 
ax25  version  2 

#  Number  of  frames  that  will  be  allowed  to  remain 

#  unacknowledged  at  one  time  on  new  AX25  connections 
ax25  maxframe  1 

#  Poll  threshold—  used  to  control  retransmission  behaviors 

#  Default  value  is  128 
ax25  pthresh  128 

#  Packet  lenght  -  if  the  I-field  (Information  field)  is  greater  than  this,  then 

#  it  will  be  fragmented  at  the  ax25  level.  ^ 

#  This  parameter  should  be  less  than  or  equal  to  the  MTU  size 

#  ax25  paclen  256 

#  - >  Double  MTU  size 

ax25  paclen  512 

#  Number  of  times  trying  to  establish  a  connection. 
ax25  retries  15 

#  Set  the  INITIAL  value  of  roundtrip  time  in  milliseconds  when 

#  a  new  connection  is  established. 
ax25  irtt  2000 
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#  Set  the  AX25  idle  'keep  alive'  timer  in  millisec. 
ax25  t3  60000 

#  Set  the  AX25  link  'redundancy'  timer  in  sec. 
ax25t4  1800 

#  Set  timer  type  for  retransmission  and  recovery 
ax25  timertype  linear 

#  Set  the  number  of  byte  that  can  be  pending  on  an  AX25  recieve  queue 

#  beyond  which  I-frame  will  be  answered  with  RNR  (Reciever  Not  Ready) 
ax25  window  2048 

#  Set  the  AX25  retransmission  ^'backoff '  limit  for  each  successive 

#  transmission  to  prevent  'congestive  collapse'  on  a  loaded  channel. 
ax25  blimit  5 

#  ????? 

ax25  smartroute  off 
#  ????? 

ax25  maxwait  9000 

#  Set  the  text  and  time  interval  in  seconds  between  broadcasts. 

#  Text 

#  ax25  bctext  "Testing  Beta  release  01/15/97,  TNOS/DOS  version  2.20" 

#  Time  interval 

#  ax25  bcinterval  30 

#  Standard  PC  asychronous  interface  (com  port) 

#  Using  com2  address  0x2f8,  intrp.  request  3,  ax25  protocal 

#  ,  and  a  kiss  TNC,  MTU  is  256  bytes 

#  By  defaults  DP  datagrams  are  sent  in  UI  frame 

#  COMl  —  This  is  a  modem  (modO)  in  NPS2 
#attach  asy  0x3 f8  4  slip  modO  1024  256  19200 

#COM2 

#  attach  asy  0x2f8  3  ax25  axO  1024  256  19200 

#  - >  COM2  with  double  Buffer  Size  (2048)  &  Double  MTU  (512) 

#attach  asy  0x2f8  3  ax25  axO  1024  256  19200 

attach  asy  px2f8  3  ax25  axO  2048  512  19200 

#  Serial  Line  Internet  Protocol  on  COM  2 
#attach  asy  0x2f8  3  slip  axO  2048  512  19200 

#  Set  the  interface  description  to  the  strings  specified 

ifconfig  axO  description  "440  MHz-- 19200  baud,  TCP/IP  network,  D4-10  transiever" 
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#  - Attach  an  Ethernet  Interface  -->  enO,  txqien  =  8,  mtu  =  1500 

#  attach  packet  FxFOO  ethemet  8  1500 

#  ifconfig  enO  ipaddress  131.120.20.166 

#  Add  a  permanent  entry  in  to  the  look-up  table 

#  address  resolution  protocol  (arp)  maps  the  IP  address  into 

#  the  subnet(Iink)  address  to  the  specific  IP  address 
arp  add  44.01.01.01  ax25  npsl  axO 

arp  add  44,01.01,03  ax25  nps3  axO 

#  Ethernet  arp 

#  arp  add  131.1 20.20. 1 65  ether  nps  1 1  enO 

#  Add  the  default  entry  into  the  routing  table 
route  add  default  axO  44.01.01.01 

#  route  add  nps2  axO  44.01.01.02 
#route  add  nps3  axO  44.01.01.03 

#  Ethemet  router 

#  route  add  nps  1 1  enO  131.1 20.20. 1 65 

#  Invoke  a  device-specific  control  routine.  On  a  KISS  TNG  interface, 

#  this  sends  control  packets  to  the  TNG 

#  Enable  the  hardware  control 
param  axO  DTR  1 

param  axO  RTS  1 
trace  axO  21 1 

#  Domain  name  server 

domain  dns  on  #  Turn  on 

domain  ttl  7200  #  Time-to-Iive  of  domain  name  server  in  sec. 

domain  addserver  44.01.01.01  #  npsl  is  also  a  domain  name  server— hostid 

domain  maxwait  60000  #  Set  time-out  for  the  dns 

domain  suffix  ampr.org.  #  Default  domain  name  suffix 
domain  translate  off  #  Turn  off  the  translation  from  IP  address 

#  dot  notation  into  a  symbolic  name 

domain  subnet  off  #  Translate  subnet  IP  address  and  broadcast  addresses 

domain  verbose  off  #  Flag  controlling  return  of  a  full  name 

domain  update  on  #  Uodate  domain  file 

domain  cache  size  200  #  Local  memory  cache  size 

domain  cache  clean  on  #  Set  the  discard  of  expired  resource  records 

domain  cache  wait  600  #  Set  the  interval  in  sec.  to  wait  for  additional 

#  activity  before  updating  the  domain.txt  file 

#  TGP  Global  parameters 
tcp  irtt  1500 

tcp  window  4096 
tcp  mss  966 
tcp  timer  linear 
tcp  syndata  on 


80 


tcp  maxwait  60000 

tcp  trace  on  #  Turn  on  trace  for  tcp  level 

# 

ifconfig  encap  mtu,576 

#  Global  IP  parameters 
ip  ttl  255 

#  This  parameter  is  not  used  for  TNOS  v,  2.21 

#  ip  encapnew  on 

#  Server 
start  ax25 

#  Converse 

start  convers  3600 

#  Finger  Server 
start  finger  . 

#FTP 
start  ftp 

#  telnet 
start  telnet 

#  Start  all  kinds  of  servers 
#start  info 

#start  news 
#start  remote 
#start  smtp 
#start  ttylink 
#start  tutor 

#  smtp  parameters 
#smtp  timer  600 
#smtp  max  4 
#smtp  trace  0 
#smtp  usemx  on 
#smtp  batch  on 
#smtp  header  on 
#smtp  sendlzw  on 
#smtp  reclzw  on 
#smtp  bidcheck  on 
#smtp  notify  on 
#smtp  quiet  off 
#smtp  t4  600 
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#  FTP  parameters 
ftype  i 
ftptdisc  600 
ftpmaxclients  2 


#  Converse  parameters 
conv  mycall  nps2 
conv  hostname  nps2 
conv  interface  axO 
conv  header  on 

conv  hmaxq  8192 
conv  umaxq  1024 
conv  t4  600 
conv  maxwait  120 

conv  motd  "This  is  the  CONVERS  MODE" 
conv  sysinfo  "New  TNOS  server  nps2.ampr.org" 

#  Switch  the  TNC  into  the  KISS  mode 
#comm  axO "  " 

#comm  axO  "int  kiss" 

#comm  axO  "reset" 

#  TxDelay 

#  param  axO  1  20 
#param  axO  1  1 

#  Persist  0  —>  255 

#  param  axO  2  127 
#param  axO  2  255 

#param  axO  3  10 
#param  axO  4  0 

#  Half-Duplex 

#  param  axO  5  0 

#  Full-Duplex 
#param  axO  5  1 

#  Time  measurement  in  sec. 
isat  on 

#  Recoding  for  telnet 
record  on 
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#  This  file  is  created  by  Nimit...  as  a  test  file 
#23  Jan  1997 

#  Anonymous  login  requires  no  password 
guest  *  /tnos21  7 

#Test 

#  NOTICE  ***** 

#  After  the  first  run  the  password  'nimit'  is  hashed  to  be 

#  the  'number  code'  below  and  re  write  back  to  the  replace  the 

#  given  password  below 

#  Permission  7  is  read(l)  +  write(2)  +  delete(4)  =  7 

npsl  46a9c5c3a3a021954125a6145cc05350/tnos21  7 
nps3  f3fd23386703a8d550c81bad8ef7ebf9  /tnos21  7 
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#  This  is  a  domain.txt  file. 

#  This  file  translates  the  CALLSIGN  into  IP  addresses 

#  A  means  'Address' 


nps3.ampr.org.  IN 

A 

44.1.1.3 

npsLampr.org.  IN 

A 

44.1.1.1 

nps2.ampr.org.  IN 

A 

44.1.1.2 

npsi  1. ampr.org. 

IN 

A  131.120.20.165 

nps22.ampr.org. 

IN 

A  131.120.20.166 
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APPENDIX  B:  COLLECTED  DATA  POINTS 
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EXp-*l 


Bytes 

File  Size  tn 

Kbytes 

»/arious  scales 

Iog_b10  Ic^_b2 

trial  #1 

Time  (SEC.) 
trial  #2 

trial  #3 

trial  #4 

Sum 

avg. 

T#1 

Speed  Qbytes/Sec.O 

T#2  T#3  T#4  sum 

avg 

185 

0.2 

-0.7 

-2.4 

1 

1 

1 

1 

4 

1 

165 

185 

159 

176 

685 

171.25 

386 

0.4 

-0.4 

-1.4 

1 

1 

1 

1 

4 

1 

278 

266 

282 

267 

1093 

273.25 

612 

0.6 

-0.2 

-0.7 

2 

2 

2 

2 

8 

2 

258 

247 

253 

221 

979 

'  244.75 

1222 

1.2 

0.1 

0.3 

3 

3 

7 

2 

15 

3.75 

401 

394 

154 

419 

1368 

342 

2460 

^5 

0.4 

1.3 

75 

4 

7 

4 

90 

22.5 

32 

515 

334 

532 

1413 

353.25 

4900 

4.9 

0.7 

2.3 

7 

7 

22 

7 

43 

10.75 

682 

692 

213 

654 

2241  • 

560.25 

9780 

9.8 

1.0 

3.3 

12 

29 

12 

27 

80 

20 

755 

328 

753 

354 

2190 

547.5 

20759 

20.8 

1.3 

4.4 

34 

24 

41 

40 

139 

34.75 

595 

845 

501 

424 

2365 

591.25 

41518 

41.5 

1.6 

5.4 

51 

53 

53 

128 

285 

71.25 

803 

774 

778 

322 

2677 

669.25 

89869 

89.9 

2.0 

6.5 

141 

142 

228 

141 

652 

163 

634 

632 

393 

636 

2295 

573.75 

186565 

186.6 

2.3 

7.5 

391 

419 

516 

395 

1721 

430.3 

476 

444 

361 

471 

1752 

438 

283261 

283.3 

2.5 

.8.1 

444 

584 

547 

686 

2261 

565.3 

637 

484 

517 

421 

2059 

514.75 

529601 

529.6 

2.7 

9.0 

1010 

810 

937 

975 

3732 

933 

524 

653 

565 

542 

2284 

571 

960696 

960.7 

3.0 

9-9 

2062 

1423 

2252 

2801 

8538 

2135 

465 

674 

426 

342 

1907 

476.75 

1 268621 

1268,6 

3.1 

10.3 

2331 

3252 

2988 

1944 

10515 

2629 

544 

390 

424 

652 

2010 

502.5 

1884471 

1884.5 

3.3 

10.9 

3493 

4951 

3808 

7108 

19360 

4840 

539 

380 

494 

256 

1669 

417.25 
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Bytes 

File  Size  in 

Kbytes 

various  scales 

Jog_b10  log_b2 

trial#  1 

Tin>€  (SEC.) 

tria!#2 

trial#3 

185 

0.2 

-0.7 

-2.4 

1 

1 

1 

386 

0.4 

-0.4 

-1.4 

1 

1 

1 

612 

0.6 

-0.2 

-0.7 

2 

2 

2 

1222 

1.2 

0.1 

0.3 

3 

3 

3 

2460 

2.5 

0.4 

1.3 

4 

4 

4 

4900 

4.9 

0.7 

2.3 

6 

6 

6 

9760 

9.8 

1.0 

3.3 

10 

10 

9 

20759 

20.8 

1.3 

4.4 

20 

17 

17 

41518 

41.5 

1.6 

5.4 

37 

31 

31 

89869 

89.9 

2.0 

6.5 

79 

65 

65 

186565 

186.6 

2.3 

7.5 

167 

134 

134 

283261 

283.3 

2.5 

8.1 

238 

200 

200 

529601 

529.6 

2.7 

9.0 

449 

378 

372 

960696 

960.7 

3.0 

9.9 

814 

675 

703 

1268621 

1268.6 

3.1 

10.3 

1076 

894 

929 

1884471 

1884.5 

3.3 

10.9 

1606 

1323 

1327 

trial#4 

Sum 

avg. 

T#1 

Speed 

T#2 

bytes/Sec. 

T#3  T#4 

sum 

avg 

1 

4 

1 

159 

166 

196 

197 

718 

179.5 

1 

4 

1 

280 

279 

271 

279 

1109 

277.25 

2 

8 

2 

258 

254 

272 

268 

1052 

263 

2 

11 

2.75 

396 

394 

406 

441 

1637 

409.25 

4 

16 

4 

504 

503 

550 

551 

2108 

527 

7 

25 

6.25 

724 

728 

797 

670 

2919 

729.75 

9 

38 

9.5 

890 

893 

1028 

1029 

3840 

960 

17 

71 

17.75 

1016 

1207 

1207 

1192 

4622 

1155.5 

31 

130 

32.5 

1116 

1311 

1307 

1308 

5042 

1260.5 

65 

274 

68.5 

1137 

1367 

1370 

1368 

5242 

1310.5 

132 

567 

141,8 

1111 

1388 

1391 

1403 

5293 

1323.25 

200 

838 

209.5 

1188 

1411 

1431 

1409 

5439 

1359.75 

395 

1594 

398.5 

1178 

1399 

1422 

1340 

5339 

1334.75 

676 

2868 

717 

1179 

1422 

1364 

1420 

5385 

1346.25 

891 

3790 

947.5 

1178 

1417 

1364 

1423 

5382 

1345.5 

1322 

5578 

1395 

1172 

1424 

1420 

1425 

5441 

1360.25 
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EXp.  -ft  5 


Bytes 

File  Size  in 
Kbytes 

various  scales 

logblO  log_b2 

trial#  1 

Time  (SEC.) 

trial#2 

trial#3 

trial#4 

Sum 

avg. 

T#1 

Speed  byies/Sec. 
T#2  T#3  T#4 

sum 

avg 

185 

0.2 

^.7 

-2.4 

1 

1 

1 

1 

4 

1 

274 

279 

276 

262 

1091 

272.75 

386 

0.4 

-0.4 

-1.4 

1 

1 

1 

1 

4 

1 

377 

386 

375 

377 

1515 

378.75 

612 

0.6 

-0.2 

-0.7 

1 

1 

1 

1 

4 

1 

397 

393 

386 

383 

1559 

389.75 

1222 

1.2 

0.1 

0.3 

2 

2 

2 

2 

a 

2 

541 

544 

550 

547 

2182 

545.5 

2460 

2.5 

0.4 

1.3 

3 

3 

3 

3 

12 

3 

733 

722 

721 

724 

2900 

725 

4900 

4.9 

0.7 

2.3 

4 

4 

4 

4 

16 

4 

1005 

990 

964 

998 

3977 

994.25 

9780 

9.8 

1.0 

3.3 

8 

8 

8 

8 

32 

6 

1181 

1216 

1187 

1218 

4802 

1200.5 

20759 

20.8 

1.3 

4.4 

IS 

15 

15 

15 

60 

15 

1322 

1374 

1356 

1375 

5429 

1357.25 

41518 

41.5 

1.6 

5.4 

28 

28 

28 

28 

112 

28 

1463 

1461 

1465 

1470 

5859 

1464.75 

89869 

89.9 

2.0 

6.5 

60 

59 

62 

59 

240 

60 

1491 

1511 

1437 

1496 

5937 

1484.25 

186565 

186.6 

2.3 

7.5 

123 

123 

121 

120 

487 

121.8 

1507 

1508 

1534 

1543 

6092 

1523 

283261 

283.3 

2.5 

8.1 

186 

183 

183 

183 

735 

183.8 

1518 

1543 

1545 

1545 

6151 

1537.75 

529601 

529.6 

2.7 

9.0 

354 

342 

342 

353 

1391 

347.6 

1493 

1546 

1547 

1499 

6065 

1521.25 

960696 

960.7 

3.0 

9.9 

636 

623 

624 

620 

2503 

625.8 

1509 

1540 

1538 

1548 

6135 

1533.75 

1268621 

1268.6 

3.1 

10.3 

835 

825 

838 

835 

3333 

833.3 

1518 

1537 

1512 

1518 

6085 

1521.25 

1884471 

1884.5 

3.3 

10.9 

1240 

1225 

1225 

1225 

4915 

1229 

1519 

1537 

1537 

1537 

6130 

1532.5 
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ROUTING 


rile  Size  in 

Bytes 

various  scales 

Kbytes  c 

Index 

T#1 

Time  (SEC.) 
T#2 

T4f3 

Tvr4 

185 

0.185 

1.) 

1 

1 

1 

1 

366 

0.386 

2.) 

1 

1 

1 

1 

612 

0.612 

3.) 

2 

2 

2 

2 

1222 

1.222 

4.) 

3 

3 

3 

3 

2460 

2.46 

5.) 

5 

5 

5 

5 

4900 

4.9 

6.) 

7 

7 

7 

7 

9780 

9.78 

7.) 

12 

12 

12 

12 

20759 

20.759 

a-) 

22 

22 

22 

22 

41518 

41.518 

9.) 

42 

42 

42 

42 

89869 

.89.869 

10.) 

88 

88 

88 

88 

186565 

186.565 

11.) 

226 

196 

184 

191 

283261 

283.261 

12.) 

272 

272 

288' 

276 

529601 

529.601 

13.) 

519 

529 

528 

517 

960696 

960.696 

14.) 

942 

965 

956 

943 

1268621 

1268.621 

15.) 

1249 

1245 

1250 

1257 

1884471 

1884.471 

16.) 

1862 

1875 

1865 

1862 

Full-Duplex  Radio  Simulated  Lmk 


Speed  byies/Sec 


Sum 

avg. 

Index 

T^?1 

T<f3 

T#4 

sum 

avg 

4 

1 

.  ) 

191 

178 

167 

164 

720 

180 

4 

1 

2) 

230 

260 

292 

2S2 

1  144 

286 

8 

2 

3.) 

270 

230 

273 

270 

1043 

260.75 

12 

3 

4.) 

392 

353 

396 

352 

1493 

373.25 

20 

5 

5.) 

467 

461 

467 

462 

1857 

464.25 

28 

7 

6.) 

675 

666 

666 

669 

2678 

669.5 

48 

12 

7.) 

802 

797 

802 

801 

3202 

800.5 

88 

22 

8.) 

923 

924 

912 

922 

3681 

920.25 

168 

42 

9.) 

983 

976 

983 

982 

3924 

961 

352 

88 

10.) 

1016 

1020 

1016 

1017 

4069 

1017.25 

797 

199.3 

11.) 

822 

949 

1011 

975 

3757 

939.25 

1110 

277.5 

12.) 

1040 

1038 

980 

1018 

4076 

1019 

2093 

523.3 

13.) 

1019 

1000 

1002 

1023 

4044 

1011 

3806 

951.5 

14.) 

1019 

994 

1004 

1018 

4035 

1008.75 

5001 

1250 

15.) 

1015 

1018 

1014 

1008 

4055 

1013.75 

7464 

1866 

16.) 

1012 

1004 

1010 

1012 

4038 

1009.5 
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ovY\p<xr\^OTi  I 


Ftle  Size  m 

various  scales 

CompU; 

ison 

Comparison 

Bytes 

Kbytes 

log_bl0  log_b2 

Time  avg. 

Speed  Avg 

1 

^  2 

#  3 

#4 

#  1 

#  2 

#  3 

#4 

165 

0.2 

-0  7 

-2  4 

1 

1 

1 

1 

171  ,25 

179.5 

272.75 

180 

386 

0.4 

-0,4 

•1  4 

1 

1 

273.25 

277.25 

378.75 

286 

612 

0.6 

-0.2 

-0.7 

2 

2 

1 

2 

244.75 

263 

389.75 

260.75 

1222 

1.2 

0.1 

0.3 

3.75 

2.75 

2 

3 

342 

409.25 

545.5 

373.25  < 

2460 

2.5 

0.4 

1 .3 

22.5 

4 

3 

5 

353.25 

527 

725 

464.25 

4900 

4.9 

0.7 

2.3 

10,75 

6.25 

4 

7 

560.25 

729.75 

994.25 

669.5 

9780 

9.8 

1.0 

3.3 

20 

9.5 

8 

12 

547.5 

960 

1200.5 

i 

800.5 

20759 

20.8 

1 .3 

4.4 

34.75 

17.75 

15 

22 

591.25 

1155.5 

1357.25 

920.25 

4151S 

41.5 

1.6 

5.4 

71.25 

32.5 

28 

42 

669.25 

1 260.5 

1464.75 

981 

89869 

89.9 

2.0 

6.5 

163 

68.5 

60 

88 

573.75 

1310.5 

1484.25 

1017.25 

186565 

186.6 

2.3 

7.5 

430.3 

141.8 

121.8 

199.3 

438 

1323.25 

1523 

939.25 

283261 

283.3 

2.5 

8.1 

565.3 

209.5 

183.8 

277.5 

514.75 

1359.75 

1537.75 

1019 

529601 

529.6 

2.7 

9.0 

933 

398.5 

347.8 

523.3 

571 

1334.75 

1521.25 

1011 

960696 

960.7 

3.0 

9.9 

2135 

717 

625.8 

951.5 

476.75 

1346.25 

1533.75 

1008.75 

1268621 

1268.6 

3.1 

10.3 

2629 

947.5 

833.3 

1250 

502.5 

1345.5 

1521.25 

1013.75 

1884471 

1884.5 

3.3 

10,9 

4840 

1395 

1229 

1866 

417.25 

1360,25 

1532.5 

1009.5 
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